This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There's no single answer, that's true. In some cases, it's best to catch an exception right away, and in other cases it's best to let it propagate; in still other cases, it's best to catch it and re-throw it as another type.
If you think about an exception as a "message in a bottle", if you call a method and it throws an exception, who is that message for? If it's for you, you should catch it. If it's not, then you shouldn't.
An example: imagine you're writing a method sendMailMessage(String address, String text). It's supposed to send an email message to a given address. sendMailMessage() might open several files to get configuration information (the sender's signature, for example.) If there are file I/O exceptions while opening these files, sendMailMessage() should probabably catch them and continue on with its task, simply leaving off the signature, or using a default JavaMail configuration. The original caller doesn't really care -- it just wants the message to go through.
On the other hand, if sendMailMessage() makes the call to JavaMail to actually send the message, and JavaMail throws an exception that signifies the message couldn't be sent, well, sendMailMessage() should definitely let that one propagate (or rethrow its own wrapper exception.) This "message in a bottle" is definitely of interest to the original caller.
In my DAOs using Hibernate via Spring, even though Spring wraps the Hibernate exceptions in unchecked versions, I still catch a few that the DAO callers are likely to care about handling -- unlike connection closed or a configuration error -- and wrap them with my own unchecked DaoException subclasses: UniqueKeyViolatedException and ObjectNotFoundException.
The other thing I mentioned is that JUnit is already set up to make exception handling easy during testing. Unless you're specifically testing for the presence or absense of a particular exception, let it propagate from the test method. JUnit will catch it and report it as an error separate from a failure. Failures are things you test for that fail. Errors are for unexpected problems not under test.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com