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.
.

Relevant Pages

  • Re: Runtime error in Java 6
    ... JDK classes. ... breaks on all exceptions and you'll see what I mean. ... API development. ...
    (comp.lang.java.programmer)
  • Re: .NET and Delphis future
    ... Big name products are still being built for API. ... Real objects, decent languages, business apps ... The world's best kept secret is that an experienced programmer when writing ... desktop apps gets the most value for $ with Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Should I use "if" or "try" (as a matter of speed)?
    ... Joel Spolsky might be a great C++ programmer, ... arguments about exceptions do not hold in Python. ...
    (comp.lang.python)
  • Re: Function side effects (again)
    ... to a programmer who wrote code as shown above. ... I developed an API that was widely used at my ... They would read the API documentation, but that form of reference still ... to Fortran more or less reading line English and math. ...
    (comp.lang.fortran)
  • Should SWs API give access to all dialogues boxes & commands?
    ... Being an old VB6, programmer, I was every excited about ... API is not consistent with OOP, ... JUST AS THE OPERATOR MAKES SELECTIONS AND ... would allow for a degree of automation that has not yet been. ...
    (comp.cad.solidworks)