Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-12 22:38:58

On Mon, Jun 12, 2017 at 3:22 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> >> 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.
>
> No, not at all. This is a major misunderstanding.
>
> The big problem with exception handling is that it introduces a
> non-obvious i.e. unwritten control flow path.
>

Where is this control flow path in Noexcept? If your function returns a
value, in Noexcept you must explicitly return a value. I mean, it's how C++
works if you disable exceptions.

> >> Just enable C++ exceptions if you want exceptions.
> >
> > I agree, the question is what to do if you can't.
>
> You're looking at it in terms of working around a company's C++ design
> policy. That's the wrong way to look at it.
>
> In large orgs with varying talent, it can make managerial sense to
> globally disable C++ exceptions: they judge that for the benefit, the
> potential cost is not worth it. This is why the majority of finance and
> games users of C++ globally disable C++ exceptions.

I know, my background is in games. I didn't think of disabling exception
handling as an arbitrary decision, the assumption is that this is the best
option for the team you have. Maybe people don't want to deal with
exception safety, that's legit.

Still, I fail to see how Noexcept differs from Outcome in this aspect.
Semantically the only difference is that Noexcept doesn't force users to
use a special template in return types, but that's a good thing. If it's
preferable, they can still use a special template, and if they do, it's
trivial to design because it doesn't have to transport errors -- Noexcept
takes care of that for you.

I'll spell it out: Noexcept + optional<> ≈ Outcome