Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial

Subject: Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-01-17 07:16:19

2017-01-17 13:06 GMT+01:00 Niall Douglas <s_sourceforge_at_[hidden]>:

> >> Again, only if the damn ISO standard required compilers to refuse
> >> to compile functions which could throw exceptions inside a noexcept
> >> execution context ...
> >
> > I disagree here. In many applications I would consider functions
> > noexcept even when they can, in theory, throw. Best example is "out
> > of memory" aka "pc lit on fire". Exception handling of rare
> > exceptions is probably among the least tested control paths, so I
> > would often rather terminate in the case of an "unexpected exception"
> > than go on and gamble whether my exception handling is going to die
> > trying to overwrite my last good program state on disk.
> >
> > Therefore, compiler noise like that would probably lead to random
> >
> > try{...}catch(...){}
> >
> > inside all noexcept functions rather quickly.
>
> An absolutely valid point. One of the big reasons for using something
> like Outcome is so one can segment really serious "this is totally
> unexpected" type errors like bad_alloc from the routine errors.
>
> However the point was about the quality of implementation of noexcept in
> C++ 11. Most on the C++ committee did (and do) not see the inversion of
> execution flow as anything special. They consider it as just another
> execution path, and hence noexcept got the unhelpful spec it did.
>
> One thing I felt noexcept really lacked was defaulting to noexcept(auto)
> which means "this function gets noexcept from the things it could
> potentially call" i.e. if everything it could call is noexcept, it too
> becomes noexcept and all extern "C" functions automatically get
> noexcept(true) applied to them.
>

Just for completeness: some "C" functions do throw exceptions, like qsort
if you pass it a callback that throws.

>
> Then the compiler could examine all functions called from a
> noexcept(true) function and error out if you ever call anything which
> deduces to noexcept(false) or is noexcept(false). This behaviour would
> be much more useful than the present situation in persuading people to
> write their code correctly.
>
> I did raise this proposal with a senior committee member once and I was
> told that the showstopper to that idea was the STL which would have
> needed many breaking changes.

> And now C++ 17 has resurrected dynamic
> exception modifiers i.e. throws(int) is back, I guess the ship has
> sailed and we're stuck with what we've got.
>

What do you mean here?

Regards,
&rzej;