Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-19 18:33:31

On Mon, Jun 19, 2017 at 2:58 AM, Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> 2017-06-14 21:52 GMT+02:00 Richard Hodges via Boost <boost_at_[hidden]
> >:
>
> > Exception return paths are not infinite. There are a finite number of
> > places in code that an exception can be thrown.
> >
> > The exception path is one path, the non-exception path is another. That’s
> > two in total. Exactly equivalent to an outcome<>.
> >
> > It is a fallacy to say that there are an indeterminate number of paths.
> >
> > If developers do not understand RAII, then an afternoon of training can
> > solve that.
> >
> > RAII is the foundation of correct c++. It is the fundamental guarantee of
> > deterministic object state. A program without RAII is not worthy of
> > consideration. The author may as well have used C.
> >
> > Perhaps there is an argument that says that RAII adds overhead to a
> > program’s footprint. If things are that tight, fair enough.
> >
> > Otherwise there is no excuse to avoid exceptions. I’ve never seen a
> > convincing argument.
> >
>
> The above statement almost treats RAII and exception handling as
> synonymous. But I believe this gives the false picture of the situation.
>
> RAII is very useful, also if you do not use exceptions, but have multiple
> return paths. You want to acquire the resource in one place and schedule
> its future release in one place, not upon every return statement.
>

If you adopt this programming style as a rule, there is no downside to
using exceptions.

> In case of using things like Outcome, you still want to follow RAII idioms.
>
> People who choose to use Outcome do understand RAII and will still use it.
> But RAII does not handle all aspects of failure-safety, and this is about
> these other aspects that people may choose to go with Outcome rather than
> exceptions. One example: propagating information about failures across
> threads, or "tasks".
>

There is exception_ptr for transporting exceptions between threads, which
was the only primitive that was missing for being able to accumulate
results from multiple workers.

Outcome and Noexcept are simply better alternatives for users who write or
maintain code that is not exception-safe -- better not compared to
exception handling (which in this case can not be used), but compared to
what they would likely do otherwise.

> > The fact that people are taking time to re-implement exception
> > functionality in outcome<> et al demonstrate the necessity and
> correctness
> > of exceptions.
> >
> > I have yet to see an answer to my initial question - an example of code
> in
> > which compiling without exceptions enabled and checking return types
> > instead, will add any performance benefit to the non-exceptional case at
> > all.
>
> Looking for alternatives to exceptions is not driven (this is my
> understanding) by performance. But by other factors, like explicitness.
>

More precisely, people who don't use exceptions choose to lower the level
of abstraction in error handling. Their motivation is similar to why C
programmers avoid C++, but limited to the domain of error handling.

> The only performance-related objective is that you want a task where
> failures occur and tasks with no failures to be performed in comparable
> times (rather than one being orders of magnitude slower).
>

I am yet to see hard data showing a real world example where error handling
based on exceptions is an order of magnitude slower. Maybe I should start
offering an award. :)