[tankenmate]

It's a pity that the section on exceptions didn't do a more detailed analysis on the criticism of exceptions; in my personal view I haven't liked exceptions, in a similar vein to how I'm not a huge fan of the implementation of POSIX signals or setjmp / longjmp.

Although I very much see the reason why it was developed, in effect it comes closer to a glorified form of "come from" (and people thought that goto was considered harmful).

[mabster]

I'm the opposite - I really like checked exceptions in Java because it's very easy to see how developers are handling errors and they also form part of the function signature.

Most functions will just pass on exceptions verbatim so it's better than error return values because with them the entire codebase has to be littered with error handling, compared to fewer try catch blocks.

setjmp, etc. are like unchecked exceptions, so I'm also not a fan, but I use this occasionally in C anyway.

[fauigerzigerk]

>I really like checked exceptions in Java because it's very easy to see how developers are handling errors and they also form part of the function signature.

Errors as return values also form part of the function signature in many languages.

>Most functions will just pass on exceptions verbatim so it's better than error return values because with them the entire codebase has to be littered with error handling, compared to fewer try catch blocks.

The question is whether you think that calls that might pass an error up the call chain should be marked as such. I think they should be.

I wouldn't call this "littered with error handling" just because a certain language has decided to do this in a way that resembles industrial style fly-tipping rather than just littering.

[phanimahesh]

Why would errors as return values have to propagate any farther in the codebase compared to errors as exceptions? If exceptions can be handled, so can the value based errors.

[JoelJacobson]

I think the sweet spot is to use exceptions for bugs. If the error is expected, make it data.

[tialaramex]

"Exceptions should be exceptional" gets to the heart of the problem with the entire concept of Exceptions for non-trivial pieces of software where there's more than a single programmer maintaining the complete system.

Now the library programmer has to guess whether when you - the application programmer try to Wibble a Foozle - will have ensured all the Foozles can be Wibbled, and so not being able to Wibble the Foozle is an exceptional condition, or whether you want to just try to Wibble every Foozle and get an error return if it can't be Wibbled...

One option is for every such condition you bifurcate the API. Instead of three types with a total of eight methods, maybe there are six conditions for two of those methods, and so now it is three types with over 100 methods... ouch. Good bye documentation and product quality.

[somewhereoutth]

Although INTERCAL's "come from" provided the opportunity to implement a gloriously concise multi-threading syntax/mechanism [1]!

[1] https://esolangs.org/wiki/Threaded_INTERCAL

[adalacelove]

Everybody chooses a favorite depending on their domain.

A function executes, and some error happens:

- Return error value: try to handle the error ASAP. The closer to the error the more detailed the information. Higher probability of recovery. Explicit error code handling throughout the code. Example: maybe you try again in one millisecond because the error is a very low probability but possible event.

- Exception: managing errors requires a high-level overview of the program state. Example: no space left on device, inform the user. You gather the detailed information where the error happened. The information is passed as-is or augmented with more information as it bubbles up the stack until someone decides to take action. Pros: separate error handling and happy path code, cleaner code. Cons: separate error handling and happy path code, unhandled errors.

Worst case scenario: you program in C. You don't have exceptions. You are forbidden to use setjmp because rules. A lot of errors are exposed directly to the programmer because this is a low-level language. You return error codes. Rules force you to handle every possible return code. Your code gets incorporated as an appendix to the Necronomicon.

[joostdevries]

This 2003 interview with Anders Hejlsberg gives considerations why he didn't add checked exceptions to C#. https://www.artima.com/articles/the-trouble-with-checked-exc...

[vlovich123]

Exceptions done well should outperform return value checking. However it’s very difficult to make it perform well and for some reason people prefer -> Result<T, E> instead of -> T throws E which is basically the same thing.

[hibikir]

The difference is the monadic capabilities of the result type. Thrown exceptions pepper codebases in ways that are even more unfortunate than monadic composition, which is already kind of iffy, but at least has generic transforms for error recoveries, turning errors to successes of a different type and so on. You end up with far less boilerplate.

[naasking]

They're not the same since exceptions typically require non-local control-flow, where Result types require local control flow.

[codr7]

Basically the same thing except the former is pessimistic and the latter optimistic.

[adastra22]

How do you feel about algebraic effects?