Alternatives to exceptions for error handling

[sighoya]

On Sunday, 29 November 2020 at 23:20:13 UTC, Roman Kashitsyn 
wrote:
>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.

They share anyway the same problem:

Deterministic error handling with finite enumerable error types.

It wasn't only the problem of penetrating error messages when 
dealing with non caught exception handling in Java, but also the 
pressure to up propagate all the newly created downstream 
exceptions requiring extending the throws section of all function 
signatures depending on it.

And Rust didn't improve anything regarding that, but no one would 
ever criticize that because its Rust.

>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.

Yep, that happens but is generally bad practice. For this kind of 
problem chained exception are useful, because each caller is 
adding his context onto the error object, the last caller is then 
able providing a more meaningful error message based on the 
messages and types of errors before.
There is even no need to throw the nested exception though I like 
a more than few in this regard.
Maybe an option to print only the outermost exception per default?