Re: Why catch specific exceptions
Tom Anderson wrote:
On Sun, 14 Jun 2009, Karl Uppiano wrote:
"Frank Cisco" <tdyjkdftyujdtjyj@dtyjdtyjdtyjdty.com> wrote in message
news:9e_Yl.51077$2t7.35768@newsfe16.ams2...
Why not wrap everything around 'throws Throwable' and
'try{...}catch(Throwable t)' then deal with the error by catching it
and dealing with each case with instanceof?
Declaring everything throws Throwable simply says that something bad
might happen, but I'm not telling you what it is. You have to guess.
It compiles, but it isn't very helpful to the eventual consumers of
your method.
As for catching Throwable and using instanceof to sort it all out,
consider this (13 lines)...
try {
...
} catch (Throwable t) {
if(t instanceof IOException) {
// cleanup I/O problem
} else if (t instanceof NullPointerException) {
// cleanup NPE problem
} else if (t instanceof IllegalArgumentException) {
// cleanup IAE problem
} else if (t instanceof Throwable) {
throw t; // can't handle it -- rethrow
}
}
...vs. this (nine lines)...
try {
...
} catch (IOException ioe) {
// cleanup I/O problem
} catch (NullPointerException npe) {
// cleanup NPE problem
} catch (IllegalArgumentException iae) {
// cleanup IAE problem
}
... same logic.
And if you want to use any class-specific features of the exception,
like calling getSQLState() on an SQLException, you have to add a cast
inside the instanceof, so that's yet another line.
I don't know how much use there is counting lines (it's only typing and
reading, after all), but separate catch blocks allow at least two useful
things. First, one can tailor the response if only the wording of the log
message (you *are* logging exceptions, right?), as well as the kind of
exception-specific logic Tom mentioned. Second, catching 'Throwable' or even
'Exception' is a bad practice, in part for the reasons Pete mentioned.
There is at least one fundamental dichotomy in handling the 'Exception'
hierarchy, checked vs. unchecked exceptions. Loosely speaking, runtime
exceptions represent programmer error and checked exceptions represent
environmental issues like an I/O failure. That argues for two different kinds
of handling right there. Anything outside of 'Exception' types, namely
'Error' and other 'Throwable' tosses, is usually such a huge fubar as to
require application shutdown.
We should not look at programs only through the lens of initial authorship.
By definition, successful programs will spend much more time in maintenance
cycle than in development cycle. Going through the very, very effortless step
of adding a few extra stanzas of 'catch' block document the code and provide
evidence of the author's thoughtful attention, both priceless for maintainers.
Conversely, a 'catch ( Throwable thr )' evidences a sloppy, lazy author and
raises red flags for maintainers, and does nothing to document the situations
the program expects to find.
That said, in production systems a final 'catch ( Exception exc )' after the
explicit catches can sometimes help a production system with rigid uptime
requirements by allowing logging of unexpected programmer errors (it should
only ever catch 'RuntimeException' occurrences in practice) and continued
application action. Of course, it's also dangerous to continue to run an app
that has just proven itself buggy.
There's generally no point to continuing to run an app after hitting an
'Error' or other non-'Exception' 'Throwable' (after logging the problem and
notifying the console, it goes without saying).
--
Lew