Subject: Re: [boost] Noexcept
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-19 21:41:54
2017-06-19 20:33 GMT+02:00 Emil Dotchevski via Boost <boost_at_[hidden]>
> 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 <
> > >:
> > > 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.
> > > 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
> > > 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
> > People who choose to use Outcome do understand RAII and will still use
> > 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.
To somewhat challenge this statement, The following is an example of how I
would use Boost.Outcome if I had it available at the time when I was
solving this parsing problem:
This tries to parse (or match) the string input, where I expect certain
syntax, into a data structure.
It is not performance-critical, I do not mind using exceptions, but I still
prefer to handle situations where the input string does not conform to the
expected syntax via explicit contrl paths. A number of reasons for that:
1. I want to separate resource acquisition errors (exceptions are still
thrown upon memory exhaustion) from input validation.
2. Some debuggers/IDEs by default engage when any exception is thrown. I do
not want this to happen when an incorrect input from the user is obtained.
3. I want validation failers to be handled immediately: one level up the
stack. I do not expect or intend to ever propagate them further.
And this code still throws exceptions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk