Re: [boost] [outcome] "sea of noexcept, islands of throwing"

Subject: Re: [boost] [outcome] "sea of noexcept, islands of throwing"
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-17 07:27:41

> Niall,
> I moved this to another thread, as I believe it is quite independent of the
> documentation review.
> 
> I am trying to understand the concept of "sea of noexcept, islands of
> throwing", and its significance.
> 
> First, is this programming technique the primary motivation for
> Boost.Outcome? In the docs, I only saw a small mention of it, but from your
> replies it looks like this is an important part of the library. But I might
> be wrong.

It is one of the primary motivations. I've been writing "sea of
noexcept" code for some time now. I've been very pleased with its
balance between letting you break into STL usage inside the
implementation of some function, yet code calling that extern function
can be compiled with C++ exceptions disabled. I just came out of a
contract working in the games industry and that design pattern gained a
lot of adherents quickly because basically, it's very useful and doesn't
disturb existing practice.

> This "sea and islands" are quite similar to what is described in P0364R0
> ("Report on Exception Handling Lite (Disappointment) from SG14"). The
> authors argue that if the exception control flow is indicated explicitly,
> the compiler has a better chance of performing optimizations.
> 
> I understand that your goal (with the Outcome library) is to offer
> something more modest, but implementable in C++. You are saying, that the
> C++ compiler can implement similar optimizations, provided that all the
> try-catch-throw flows are confined to one translation unit. Did I get it
> right?

I think that SG14 paper is now a little out of date. Members of SG14
have tried on many occasions to prove C++ exceptions are bad in real
world code bases. One fellow even went through his financial trading
program replacing all his error codes with exception throws, recompiled
with the expectation it would be horrendous, and surprise surprise he
could find no statistically significant performance difference.

Some on SG14 still believe exceptions are bad for performance no matter
what, but I think given the accumulating evidence that claim needs to be
qualified with "for certain hot code paths". And I think that claim is
fair, it's totally possible that for some hot code path exception throws
will murder performance. Equally, they might make it much quicker.
Depends on the hot code path.

The main goal for Outcome is to make it *easier* to write code which is
C++ exceptions disabled through the trunk of the tree, but branches and
especially leaves may use exceptions extensively. Outcome just wraps up
the existing facilities in C++ 11 (error_code, exception_ptr) into a
more convenient package. It does no magic, and I would expect code using
Outcome to not become magically faster than code not using Outcome.

What I do claim and hope and expect is that code using Outcome is not
*slower* than code not using Outcome, both in compile times and in
runtime performance. I've thrown everything I know at ensuring both.

In terms of whether your particular application *ought* to not throw
exceptions in its "trunk", that really depends on the application. I
think for large, complex C++ codebases there is a very strong argument
that exceptions ought to never be thrown across an extern boundary. Not
doing this reduces the number of possible execution paths through a
large code base exponentially. That means fewer surprises when someone
modifies some code five years from now in a ten million line code base.

> The authors of P0364R0 claim that in some business domains, like video
> games, if you encounter a failure to acquire resources, you might as well
> terminate the program. For this reason RAII is not really that important
> there: you want to shut down the app rather than clean up and continue. Is
> it also what you are saying?

Not at all. If anything, the opposite. I've never been fond of ignoring
errors, not ever, even in high performance code.

> Do you also intend to support something like 'panic mode' in Rust? I do not
> know Rust, but I understand that this 'panic mode' is shut down the program
> but with resource cleanup.

I leave that entirely up to the programmer using Outcome. Outcome's
purpose is to provide an ultra ultra light weight common error handling
infrastructure that loses no information. So if some random third party
library linked far far away throws some custom exception, Outcome based
code will transmit that totally unknown and unknowable error state
through code which has no knowledge of it without losing information.

> Sorry, my questions are quite random. But I am trying to understand the
> idea.

It's no problem. Most on the committee think exceptions are the correct
way of reporting errors because they clutter up code the least. I think
that's right for a range of code bases. I also think that's wrong for a
range of code bases. Depends on the code base. In particular, for some
code bases you really must *require* the programmer to explicitly code
what happens when an error occurs. What you see before you is always
taken more seriously by other programmers than automatic execution paths
chosen silently for you by the compiler.

Niall

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