Your exception handling here looks kind of strange. First, your main() declares "throws Exception" instead of handling all exceptions inside. That's wrong. Since your main process is, indeed, your application, why are assuming that it's ok for it blow up? You need to catch any exceptions that reach the top level of your application - e.g. your main() - and handle them in a graceful way, even if they represent programming errors. At the very least you need to catch, log the full stack trace, and display a more or less friendly message to the user. Logging will ensure that the error info does not get lost, but it is not necessary to spew the exception in the face of the user (assuming that you logs may go into separate files for admins to look at, while the console output is more "user friendly".) In other words,
you should put a try/catch/finally around the main() method. In your other methods (subroutines) you can handle specific exceptions that you want to handle in a distinct way. No need to handle and rethrow anything else. Just let everything else propagate to the catch in main(). This would save you lots of time mand effort placing unnecessary try/catches in almost every method.
Another issue that I see is that your methods catch (and, perhaps handle or swallow) a specific type of checked exception, and nothing else. What this means is that you may catch that specific exception but let other (runtime) exceptions slip through the cracks and go unreported. It is never enough to handle just the checked exceptions because they are only a subset of all exceptions that may occur in your application.
There is an excellent article I have recently read:
http://constv.blogspot.com/2009/08/error-handling-and-exceptions-in-java.html
I highly recommend reading it. It answered a lot of my questions, and it explains things much better than I can. I think it is one of the better ones out there on exceptions and error handling in general.
HTH,
Alec
P.S. As for the Sun's "tutorial" on handling exceptions, I think it is very obsolete and just wrong. They recommend using checked exceptions "when the client is expected to recover"... That is just wrong. How can you write a method and foresee what its callers would want to do with it in various scenarios. Some may want (be able) to recover, some might have no knowledgeof how to handle the error immediately and would have to propagate that exception further. Why impose such contract on everybody instead of simply broadcasting the error and letting whomever is interested to listen to it and catch it? Again, read the article I had mentioned above, it explains things well, I think. Ever since I read it i have been recommending it to everyone.