Hi!

Thank you for your great initiative regarding improving the C++ error handling! At least for the
industries I've been working in, error handling has been so much of a debate so people even
tend to avoid it and only look at it when bug reports are coming in.

To the point!

In the paper P0709 R2, Section 4.3.1, I find the table very helpful and think you should use that
when you communicate error handling. Herb did a good job at the ACCU19 Keynote but the
table in P0709 is spot on!

I have a couple of ideas that I would like to share with you about the table. I go backwards.

5. Alternate success.
Brilliant! Finally we have it on paper. There are so many function results that developers report
as errors.

4. Recoverable error.
Also a brilliant wording to help developers understand that errors are recoverable and must
provide at least basic exception guarantees.

3. Heap exhaustion (OOM).
I come back to that below.

2. Programming bug.
If possible, try bring in terms from ISO 24765. For example, write "Programming bug/defect/fault".
This will help developers differentiate between a defect/bug and an error.

1. Corruption of the abstract machine.
May I suggest that this is renamed something similar to "Out of Execution Resource (OOER)"? The
abstract machine is not really corrupt, it just ran out of stack. If we rename it OOER, we could treat
heap exhaustion (OOM) the same way as for Out of Stack. This will of course force us to provide
something similar to try_reserve that reports an error if not enough heap is available, just as we
get an error when asking for too many file descriptors or threads.

What do you think about my ideas?


Best regards,
Daniel Markus