Alternatives to exceptions for error handling

[Roman Kashitsyn]

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.