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

Subject: Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-17 07:06:47

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

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/