In general, you should try to catch more specific exceptions, so that you can handle the exception in a more specific manner, particular to the error at hand. For example, if you catch an IOException, depending on your application, you could maybe prompt the user to try a new file name or close down any applications using the file in question. With just an Exception handler, you wouldn�t know if that was the problem, or if there was a null pointer exception somewhere.
And if you catch a specific exception rather than a more general one, you can often allow the more general exceptions (everything but IOException in my example) to propagate up the call stack to an exception handler elsewhere that is more suited for whatever that exception is.
That said, it�s not always bad to have a catch of Exception, as long as it is the last catch block listed. We do that frequently in our GUI code, as a last level of defense against exceptions that slipped through all the other exception handlers. We have to handle them very generically, but it does prevent us from crashing part of the application because of a null pointer exception.
But Stan, your first code example only loses the stack trace for the three explicitly named exceptions. Depending what they are, maybe that's fine; maybe you don't need the stack trace. However the replacement you recommend will lose the stack trace for any exception that may occur within the try. Like, say, a NullPointerException. Which now becomes much harder to track down.
"I'm not back." - Bill Harding, Twister
Joined: Jan 29, 2003
Right. Catching all exceptions takes some extra care. In real life I'd print stack traces, too. And I'd occasionally catch something I really shouldn't try to recover from. That hasn't bit me yet, but doesn't mean it won't one day.