Re: [boost] Noexcept

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

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:
https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_example.md
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.

Regards,
&rzej;