Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-12 22:22:19

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

In the hands of programmers who understand C++ very well, that's fine.
Very high quality, predictable latency code can be written. Indeed I've
done it myself many a time - a few contracts back I wrote a fixed
latency audio processing implementation which delivered flawless audio
with sub 4ms latency irrespective of CPU and GPU load on Windows using
the STL and with C++ exceptions enabled.

The problem is the average programmer. If they come along to some code
carefully written to keep maximum latency bounded, they will more often
than not wreck the code in subtle, very hard to detect ways. Problems
can also emerge with STL implementations changing after a compiler
upgrade. There is also an argument that auditing exception throwing code
is harder in code with a 10+ year lifespan, or properly unit testing
code being developed as you may have up to twice the execution paths
which need testing.

These are the reasons you globally disable C++ exceptions. You chop off
a major source of performance uncertainty in a large code base being
changed over more than a decade.

It's also why you don't want to replace unwritten control flow with
another unwritten control flow. You want to make programmers explicitly
write down what happens when failure occurs. It makes them think about
it properly, cost its performance properly, and lets peer review audit
it properly.

>> 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. And indeed Google
and a few others. It's not mostly a technical rationale, though for
those who like to write out CPU cycle budgets for hot code paths, for
obvious reasons you never permit C++ exception throws and you never call
malloc.

Globally disabling exceptions at least eliminates some arsehole bringing
the former in, and writing a malloc link monkey patcher routine to
prevent linking hotpath objects which call malloc can help enforce the
latter. You need to make the CI fail builds where people commit stupid
stuff, that makes them back out the commit and try harder.

Niall

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