So empirical evidence on sample size of N=2 (Rust and C++) shows that when you take out exceptions from a PL [1] you get a number of mutually incompatible libraries for communicating errors. (Exceptions are controversial in C++ and many projects forbid their use.)
And then there's Go which seems to be too primitive to even facilitate custom error-handling libraries.
It makes me sad that there's no research (that I'm aware of) about ergonomics of exceptions. They're easily thrown, but as they're dynamically scoped, it's hard to know what to catch when you actually want to retry an operation instead of just catching a top-level exception type and logging it.
Failing and aborting the request/ user action is the general & correct response to an error.
Retrying is relevant for a specific small segment of callsites dealing with unreliable network or hardware interactions. This fact and knowledge of it should inherently be obvious at the callsite.
I do recognize a valuable distinction between predictable and unexpected errors. In business applications, I refer to these as "business" and "technical" exceptions. Business exceptions are caused by a violation of business rules in the called layer directly, and are potentially predictable & recoverable. Technical exceptions arise from lower layers, are beyond the bounds of encapsulation, and are not recoverable. It seems the Mistake vs Error concept maps to this. I'm not much convinced about nuance beyond this.
To be honest I think both Rust and Go have fallen into a mistake of forcing every operation -- the vast majority being unrecoverable errors -- to be checked. They should just be thrown as exceptions.
Lastly many of the author's examples sound like bad error handling to me. They lack context as to the client request. If something the client could directly understand & fix is broken, it should report a business exception aka "mistake". Otherwise it should report an error without expectation of recovery.
> Retrying is relevant for a specific small segment of callsites dealing with unreliable network or hardware interactions. This fact and knowledge of it should inherently be obvious at the callsite.
Yes. However, libraries, at least in .NET world, are notoriously bad at documenting what exceptions are thrown in what circumstances. Example: trying to execute an SQL statement against a server and the network connection drops. Do I get SqlException, SocketException, or SqlException containing an inner exception that is (hopefully) SocketException or TimeoutException. Link to docs: https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlc... It mentions network outage, but specifically only for streaming operations, while most queries are decisively not in that category.
So what exception should the program catch to handle the case of network outage so that it can sleep and retry? It's also extremely difficult to test an outage of an intermediate router/switch because unplugging the network cable tells the OS that the media is gone, which immediately signals an error to programs depending on that interface. (Though possible to mock with FW rules...)
And then there's Go which seems to be too primitive to even facilitate custom error-handling libraries.
It makes me sad that there's no research (that I'm aware of) about ergonomics of exceptions. They're easily thrown, but as they're dynamically scoped, it's hard to know what to catch when you actually want to retry an operation instead of just catching a top-level exception type and logging it.