Re: Runtime error in Java 6
Lew wrote:
Other uses of exceptions tend to be an antipattern. Use of
conditional checks is usually better.
Mike Schilling wrote:
Unfortunately, exceptions that are expected (and thus caught and
ignored) abound in code that you can't do anything about, like the JDK
classes. Try running some Java program under a debugger that breaks
on all exceptions and you'll see what I mean.
There's one sensibility for application development, and another for API
development. The API part throws Exceptions, in part because an API writer
has to be sure to lock down future, unguessable (ab)uses of the library. The
application part "knows" its own logic, and what conditions cause an API call
to throw an Exception, so it can and should guard against those conditions /a
priori/, not permitting the Exception. Often, not always.
Even within the same application, in parts written by the same programmer
(team), some classes will be of the application flavor, others of the API
flavor - a sort of internal API. The API part should throw Exceptions, and
the application part should prevent or catch and handle them.
The decision of which, prevent or catch, is an art and not a hard science,
IMHO. One remembers that Exceptions are expensive, and prefers to avoid them
where feasible, but pays the price for them when they are the right choice.
Guidelines, simply as rules of thumb, not law:
Unchecked Exceptions are for programmer error. These should not occur in
production, but if they do, they provide useful information for the correction.
Checked Exceptions are for anomalous but generally amenable conditions that
are out of the main algorithmic flow. They are documented and impose the
burden of dealing with them ineluctably, but usefully, in production.
Errors are for a graceful exit from the program, or module. Things are too
fubared to return to the main algorithmic flow.
Assertions prove the invariants that Exceptions (and other techniques)
establish. They shouldn't be needed in production often, but that's up to
Operations to decide. When they're needed, the programmer had better have
gotten them right.
--
Lew
All developers should spend a month working in Operations from time to time.
You will come away transformed. Not very happy, but transformed.