This article is far too focused on the domain of web programming where you almost always propagate the error to the main loop. However, in a large amount of pro

This article is far too focused on the domain of web programming where you almost always propagate the error to the main loop. However, in a large amount of programs you actually are able to handle the error at the call site. Furthermore, whether an error can be handled or not is a property of the caller, not the callee. If you're writing a public api and don't know your caller then checked exceptions are safer, and callers who just want to propagate the error can still write an api wrapper that rethrows them unchecked. I do agree that checked exceptions are poorly implemented in Java though. In my dream world checked exceptions would be replaced by Either types which wrap a value or an error and there would be macro-methods for both propagating them and throwing them unchecked. There would also be union types for representing a set of possible named exceptions. Rust is probably the language closest to this. Finally, if you're writing internal code for something like a web api, then of course you should stay far away from checked exceptions and rethrow them unchecked as early as possible when calling external code.