I think of this way; there are broad categories of exceptions that you can handle and specific exceptions. But those exceptions are significantly smaller than

I think of this way; there are broad categories of exceptions that you can handle and specific exceptions. But those exceptions are significantly smaller than the set of all possible exceptions my code (and the framework code) can trigger. I shouldn't have to worry about every possible exception, just ones I can handle. Checked exceptions/errors means you have to deal with the minutiae. For your example if retrying network, I prefer to simply have a "ShouldRetry" property/interface on the exception itself since the triggering code has the best knowledge of how it should be handled. No need to know every possible network exception and sort them into retry or not retry. > Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? My favorite error handling is when you can just put a single handler at the event-loop of a UI based project. On exception you just show them the message and continue running. The stack unwinding code ensures the application maintains correct state and that the operation is unwound. If the user clicked "save" and a failure occurred they get the message and can retry if they want.