Alternatives to exceptions for error handling
romankashicin at gmail.com
Sun Nov 29 18:17:02 UTC 2020
On Tuesday, 24 November 2020 at 20:30:33 UTC, Jonathan M Davis
> 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
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.
More information about the Digitalmars-d