@juliobiason I haven't read the whole article yet, but it seems to me there's a need to distinguish between "expected" error conditions and unexpected ones. The latter should usually result in a crash due to the fact that it means you're probably in an unexpected state. This can be implemented using exceptions, but having the language directly support the distinction would be better. An example would be signals vs error messages in Erlang. You *can* catch signals but it's rare.

@juliobiason It can be hard to know in advance which errors the caller expected, but in Erlang it's common to handle results using pattern matching anyway, and an unhandled result will result in a crash just like an unhandled exception in another language.

Of course, Erlang has nonlocal returns using throw/catch these days, but that's explicitly targeted at nonlocal returns, not errors.

@juliobiason So I guess what I'm saying is that it's not so much that exceptions get abused for nonlocal returns as it is that exceptions are an abuse of a nonlocal return mechanism to signal errors.

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!