It may not be recoverable locally, but the caller may know how. Consider Files.createFile. It throws if the target already exists. That method has no way of kn

It may not be recoverable locally, but the caller may know how. Consider Files.createFile. It throws if the target already exists. That method has no way of knowing what the recovery is, however, the caller might. It could be that the caller wants to explode, but maybe its part of some kind of singleton launch where the recovery is to pass some piece of data off to whoever created the file originally. Maybe this is a bad example since there’s not much interesting in the return of Files. But it’s exceptional in that it’s an abort rather than a success. That said, checked exceptions are still trash because they don’t work across thread boundaries or with futures. ExecutionException is the catch all baked into the design because they needed something. The idea could have been good though because naming error handling visible is useful. Java just has the misfortune of designing early before the kinks had been worked out and now we get nice stuff like Rust has.