RE: Improved error handling (Was: [PATCH 1/2] sequencer: factor out rewrite_file())

["Randall S. Becker" <rsbecker@nexbridge.com>]

On December 24, 2017 9:54 AM, Jeff King wrote:
> Subject: Re: Improved error handling (Was: [PATCH 1/2] sequencer: factor
> out rewrite_file())
> 
> On Sat, Nov 18, 2017 at 10:01:45AM +0100, Johannes Sixt wrote:
> 
> > > Yeah, I have mixed feelings on that. I think it does make the
> > > control flow less clear. At the same time, what I found was that
> > > handlers like die/ignore/warn were the thing that gave the most
> > > reduction in complexity in the callers.
> >
> > Would you not consider switching over to C++? With exceptions, you get
> > the error context without cluttering the API. (Did I mention that
> > librarification would become a breeze? Do not die in library routines:
> > not a problem anymore, just catch the exception. die_on_error
> > parameters? Not needed anymore. Not to mention that resource leaks
> > would be much, MUCH simpler to treat.)
> 
> I threw this email on my todo pile since I was traveling when it came, but I
> think it deserves a response (albeit quite late).
> 
> It's been a long while since I've done any serious C++, but I did really like the
> RAII pattern coupled with exceptions. That said, I think it's dangerous to do it
> half-way, and especially to retrofit an existing code base. It introduces a
> whole new control-flow pattern that is invisible to the existing code, so
> you're going to get leaks and variables in unexpected states whenever you
> see an exception.
> 
> I also suspect there'd be a fair bit of in converting the existing code to
> something that actually compiles as C++.
> 
> So if we were starting the project from scratch and thinking about using
> C++ with RAII and exceptions, sure, that's something I'd entertain[1]
> (and maybe even Linus has softened on his opinion of C++ these days ;) ).
> But at this point, it doesn't seem like the tradeoff for switching is there.

While I'm a huge fan of OO, you really need a solid justification for going there, and a good study of your target audience for Open Source C++. My comments are based on porting experience outside of Linux/Windows:

1. Conversion to C++ just to pick up exceptions is a lot like "One does not simply walk to Mordor", as Peff hinted at above.
2. Moving to C++ generally involves a **complete** redesign. While Command Patterns (and and...)  may be very helpful in one level, the current git code base is very procedural in nature.
3. From a porting perspective, applications written in with C++ generally (there are exceptions) are significantly harder than C. The POSIX APIs are older and more broadly supported/emulated than what is available in C++. Once you start getting into "my favourite C++ library is...", or "version2 or version3", or smart pointers vs. scope allocation, things get pretty argumentative. It is (arguably) much easier to disable a section of code that won't function on a platform in C without having to rework an OO model, making subsequent merges pretty much impossible and the port unsustainable. That is unless the overall design really factors in platform differences right into the OO model from the beginning of incubation.
4. I really hate making these points because I am an OO "fanspert", just not when doing portable code. Even in java, which is more port-stable than C++ (arguably, but in my experience), you tend to hit platform library differences than can invalidate ports.

My take is "oh my please don't go there" for the git project, for a component that has become/is becoming required core infrastructure for so many platforms.

With Respect,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.