Misusing java.lang.Exception

I'm currently working on the last minute preparations for the launch of a new web site for Boomer.com. We are using a pretty decent piece of software for the side, called Magnolia. However, one issue in the Magnolia source that's been bugging me is the use of java.lang.Exception in many throws/catch clauses.

This is a pretty nasty habit that Java developers should avoid. Often when building code quickly or when you're making a lot of changes, it may be tempting to engage in this habit, but it's a fairly bad idea. Let me enumerate:

1. Catching Exception may catch errors you aren't really anticipating and handle them in ways thare aren't correct or mask them from appearing higher up in the call stack where they belong. For example, you may write a piece of coding expecting some kind of database errors that should be ignored, but you end up spending an hour ro two trying to track down a problem because something throws the infamous NPE, but you were ignoring it rather than coping with it, which led to some other problem in your code 500 lines later. Not cool.
2. Catching Exception involves treating all errors the same, which is rarely the right way to handle problems. Generally, each exception should be handled differently. For example, a database connection problem shouldn't be treated the same as a failure to return an expected result. On the web, the former might result in a 500 Internal Server Error and the latter might be better described as a 404 File Not Found error. Those are very different responses.
3. Catching Exception rather than the specific exceptions masks changes to code that will affect other parts of the code. For example, if I write a piece of code that throws errors that are generally ignored, but later come back and add another function call which adds a new exception that really needs to be handled by the caller in the 4 or 5 places the method is used, I might not catch all 4 or 5 places if my throws clause just contains Exception. This isn't smart use of the static checker to help me find places where a code change might propogate elsewhere.
4. Catching specific exceptions helps to make code self-documenting and easier to read. If all the code just catches Exception or states a throws clause of Exception, that's a really poor indicator of the kinds of errors one can expect from that method. If you also don't include any JavaDoc or wait until later to add your docs, it may take a lot of deep looking to find out what errors are really possible.

If you are a Java programmer, you should avoid this trap. No matter how tempting it is, even on code you plan to use just a few times and then throw away, you ought to think about this carefully. There've been far too many times in my programming experience where a little bit of temporary throw away code suddenly became permanent because I found it more useful than anticipated or project goals changed. I don't want to write some quickie code that I then have to go back and rewrite because I hacked it together with a bunch of bad habits, if I end up reusing it. I expect most programmers don't.

Anyway, don't code stupid. You don't want to be featured on The Daily WTF. Cheers.