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

From: Jeff King <peff@peff.net>
Date: Dec 24, 2017, 14:54 UTC
Message-ID: <20171224145427.GG23648@sigill.intra.peff.net>
In-Reply-To: <c50ac174-15bd-60bc-490c-d231e3eb501d@kdbg.org>

On Sat, Nov 18, 2017 at 10:01:45AM +0100, Johannes Sixt wrote:

Show 11 quoted lines

> > 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.

-Peff

[1] I'd also consider Rust, though I'm not too experienced with it
    myself.