[dolbz]

> It was a little rushed with the whole concept of forcing everyone to handle all exceptions

Just to clarify, Java doesn't force you to handle all exceptions (maybe it did at one point in time?). Exceptions which inherit from RuntimeException are unchecked and you can choose whether to handle them or not. Exceptions which don't inherit from RuntimeException are checked

[Sandman]

That being said, I'd like to quote these passages from the official Java tutorial:

"Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."

Anyway... you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them.

So the poster of the grandparent comment really got it wrong when it comes to Java and exceptions.

[dolbz]

> you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them.

The problem with this is it affects the signature of all methods in your call hierarchy up to the point where it's handled as you're forced to declare that you throw exceptions. A simple change in one class could quickly become a breaking change involving several classes just because an exception can now occur.