Alternatives to exceptions for error handling

[Roman Kashitsyn]

On Tuesday, 24 November 2020 at 20:30:33 UTC, Jonathan M Davis 
wrote:
> On Monday, November 23, 2020 3:58:29 AM MST Jacob Carlborg via 
> Digitalmars-d wrote:
>> On Sunday, 22 November 2020 at 17:37:18 UTC,
> the ability to throw an error condition up to code that handles 
> it higher up, allowing all of the code in between to largely 
> ignore the error condition is huge, and a lot of code can get 
> pretty disgusting without that.

It's mostly the question of values: writing nice looking code 
quickly vs writing code that handles all the edge cases 
thoroughly.  It's much more fun to write the first kind of code 
and it's perfectly justified in many cases.   Though as a user 
(of an app or a library) you would probably prefer the second 
kind of code.

Thoughtful error handling never looks good, and exceptions don't 
help with that at all: try/catch syntax is very heavyweight and 
encourages you to propagate errors instead of dealing with them 
where they arise.

Exceptions also make type signatures less precise: it's hard to 
be sure I handled all the errors I can recover from if I don't 
know which errors can actually occur.  There is no way to tell 
without inspecting the full transitive closure of the code I call 
into.

So it would be nice to have an alternative to exceptions even if 
it's not going to be the default mechanism.

Herb Sutter's proposal looks OK but it doesn't solve most of the 
problems I have with exceptions:
  1. The syntax for propagating errors is OK, but the syntax for 
*handling* them is still heavyweight.
  2. All the error types are mashed into std::error, so I still 
don't know which errors are possible at each call.