Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-05-24 19:44:35

On Wed, May 24, 2017 at 12:16 PM, Ion Gaztañaga via Boost <
boost_at_[hidden]> wrote:

> On 24/05/2017 20:54, Emil Dotchevski via Boost wrote:
>
>> I don't dispute that exception handling has overhead and that you can
>> construct a toy example that shows that. However, people who choose to
>> avoid exceptions make a bigger claim, something along the lines of "in my
>> domain we can't afford exception handling overhead". I have _never_ seen
>> hard data to support this.
>>
>
> I have seen two use cases to avoid exceptions:
>
> 1) Any hard error won't be handled, because it's highly unlikely, and we
> don't want to use more space or CPU (depending on the implementation) in
> something that is very unlikely. For hard errors std::terminate or a
> log-and-die solution is a perfectly valid option for an application (e.g.
> when memory is exhausted or a logic error is detected). This could be the
> case for some games.
>
> 2) Hidden control paths are unacceptable. Typically safety or security
> critical systems where every single path or branch must be tested.
> Explicitly error handling shows every path and code review and coverage
> tools are very helpful. Writing exception safe code is error-prone,
> specially when operations that can throw can change implicitly when inner
> operations of a statement start throwing new classes. The exception type
> thrown by is not enforced by the compiler whereas the return type is fixed
> at compile time. Sometimes this makes error handling much easier.
>

Arguments similar to the ones you make in 2) can be made in support of
exception handling as well. For example, returning error codes has many
more points where bugs can occur, since failure-neutral contexts still must
be concerned with failures. Under maintenance, unrelated seemingly innocent
change in the control flow can easily introduce subtle bugs in the
error-reporting branches. This problem is amplified by the fact that these
branches are usually very difficult to test and analyze, therefore it is
critical to adopt a programming style that avoids such bugs. I would
conclude that writing exception-unsafe code is error-prone, both during the
initial development and under maintenance. I would typically recommend
writing exception-safe code even if you don't use exceptions.

That said, you're making good points, both are arguments about the
semantics of exception handling rather than the overhead of it. My initial
objection if you want to call it that is that the general attitude of
Outcome seems to be "exceptions are slow and so C++98, what are you, a
neanderthal?" :) whereas I see Outcome as lowering the level of abstraction
to where it is in other languages which force programmers to laboriously
deal with failures explicitly (which is prone to errors) -- for no good
reason at all.