I've said this often specifically in the context of golang, but while you're right that retries and similar are a common case, they are fairly similar to the 'e

I've said this often specifically in the context of golang, but while you're right that retries and similar are a common case, they are fairly similar to the 'expected' error case in the article, and can almost always be handled at precisely the place where you raise the error. In python this is @retry.retry(exceptions=[RpcException], tries=5, backoff=2, jitter=1) def my_external_rpc_call(...): .... And RpcException will only be raised beyond this if the backend is unreachable for ~30 seconds. Similarly, rpc services can abstract over this entirely, grpc (and presumably others) allow you to configure the retry policy per rpc service or method, and have it reflected everywhere that is used, without writing wrappers[0]. Which really all is to say, once you have solid libraries that handle retries of operations that are known to be error prone (file IO, network IO, things that could lock/block, etc.) you pretty quickly get into "any error implies we're totally boned". [0]: https://github.com/grpc/grpc-go/blob/f601dfac73c9/examples/features/retry/client/main.go https://github.com/grpc/grpc-go/blob/f601dfac73c9/examples/f...