Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-06-19 22:42:19

> 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

In the above code, the return type of expected<std::vector<Distrib>,
BadInput> is equivalent in all respects to 2-state variant.

If it were implemented as a boost/std::variant, then the two states could
be handled with a static visitor - which would provide a compile-time
guarantee that any future third state was not missed.

I don't think we're gaining anything with outcome, other than perhaps a
label which serves to express intent?

R

On 19 June 2017 at 23:41, Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> 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;
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>