Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-12 20:15:00

2017-06-12 20:07 GMT+02:00 Emil Dotchevski via Boost <boost_at_[hidden]>
:

> On Mon, Jun 12, 2017 at 2:42 AM, Niall Douglas via Boost <
> boost_at_[hidden]> wrote:
>
> > On 12/06/2017 09:22, Emil Dotchevski via Boost wrote:
> > > The lively debates during the Outcome review show that there is a great
> > > deal of interest in solving the problem of error handling in
> environments
> > > where C++ exception handling is unavailable.
> > >
> > > Noexcept is a new C++11 library that implements a different approach to
> > > solving the same problem. Any feedback is welcome.
> > >
> > > https://zajo.github.io/boost-noexcept/
> >
> > The use of functional throw(), try() and catch() was a design approach
> > rejected very early by me and most who have looked into this problem.
> >
> > Nobody wants to reimplement via a library exception handling with
> > exceptions disabled. It's an impoverished experience, and leads to
> > brittle code.
>
>
> Can you elaborate? My understanding is that the problem with exception
> handling is the unpredictability of the performance you'll get. Noexcept
> directly addresses that issue by not introducing the unpredictability of
> its own return type which may or may not get optimized.
>
> It also removes the redundancy of requiring types which already have a
> useful empty state to be wrapped into something like outcome<>. Nobody
> would return optional<FILE *> from a function that may fail, they'll just
> return FILE */nullptr. Returning outcome<FILE *> is similarly redundant and
> possibly inefficient.
>
>
> > Just enable C++ exceptions if you want exceptions.
> >
>
> I agree, the question is what to do if you can't.
>

There is a number of expectations people have or might have form
error-handling framework:

1. Predictable times.
2. When I forget to check for error, the computation should not silently
proceed.
3. Not polluting the function return type
4. Explicit control flows.
5. No explicit control flows.
6. Neutrality for some functions, elspecially those extern "C".
7. Being fast.
8. Being able to carry any payload.

Obviously, a framework cannot guarantee all of these, and trade-offs need
to be made. One thing that both exceptions, and outcome<>/expected<> have
is #2: when you forget that the function might fail, and it fails, the
dependent functions will not get called. In case of exceptions this is
owing to stack unwinding. In case of outcome, it is because the program
will not compile. In Noexcept, when I forget to check, the default value is
passed to subsequent functions, which may or may not be prepared for that.
I think this is what Niall is saying.

Regards,
&rzej;