Paul makes some very good points. He advocates exception handling at the level of the unit of work. The problem is what is the unit of work? As an example, I was setting up a new Jboss installation and deployment of an application that I am only getting familiar with. Catalina threw an exception about something in the configuration, but didn't log anything. Finally, JBoss caught the exception and just logged that the deployment had failed. The piece of code that found the problem could have told me what was wrong.<p>Paul says that checked exception are a horrible mistake, because they cause premature catching of exceptions, because ignoring the exception means that the programmer has to change the signature of his method. I find swallowed exceptions all over the place in reading code. And methods in the Sun libraries exacerbate the problem by throwing multiple checked exceptions that have to be swallowed. So to keep method signatures at a reasonable length, more swallowed exceptions. Generic exceptions with error codes, like SQLException, would make more sense.<p>Given the reality of Java Exception handling, I favor catching the exception at the point where a reasonable error message can be composed and logged., Then throwing an unchecked exception to be caught at the level of the unit of work.<p>Finally, Paul says always use finally to clean up your mess.