Alternatives to exceptions for error handling
romankashicin at gmail.com
Sun Nov 29 23:20:13 UTC 2020
On Sunday, 29 November 2020 at 19:52:27 UTC, Jacob Carlborg wrote:
> In many cases you don't know what to do with an error so you
> need to propagate it up the stack. For example, opening a file.
> If that fails, the function has no idea if that's a critical
> error or not. It might be a config file that is missing and the
> application cannot start without it. Or it might the that a
> user selected a file which it doesn't have permission to open.
Sure, it's not always possible to handle errors at the level they
arise, those need to be propagated.
On the other hand, most of the time the caller has even less clue
on how to deal with the error: the further you go from the point
where error happened, the less likely it's going to be handled in
a meaningful way.
Sometimes a crash with a core dump might be preferable to stack
unwinding as the core dump might contain more useful information
than a stack trace.
My main point is that it's really nice to see what can go wrong
just from the function type signature, this transforms the way
people (well, at least some of them) write software.
Checked exceptions in Java was a failed attempt to achieve this,
they brought nothing but pain and boilerplate.
I believe sum types + pattern matching + error propagation sugar
is a much nicer solution for errors that people might care to
handle. Of course, Errors don't fall into this category.
More information about the Digitalmars-d