Skip to Content.
Sympa Menu

xom-interest - OT: Exceptions Re: [XOM-interest] design principles

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Henri Yandell <bayard AT generationjava.com>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: Michael McEniry <mmceniry AT itsc.uah.edu>, <xom-interest AT lists.ibiblio.org>
  • Subject: OT: Exceptions Re: [XOM-interest] design principles
  • Date: Fri, 20 Sep 2002 18:00:24 -0400 (EDT)


On Fri, 20 Sep 2002, Elliotte Rusty Harold wrote:

> "Problems detectable in testing throw runtime exceptions"
>
> I got this idea from Bruce Eckel (Does Java need Checked Exceptions?,
> http://www.mindview.net/Etc/Discussions/CheckedExceptions) and Joshua
> Bloch (Effective Java, particularly Item 40--Use checked exceptions
> for recoverable conditions and runtime exceptions for programming
> errors--and 41--Avoid unnecessary use of checked exceptions). Bloch
> is especially clear that precondition violations should cause runtime
> exceptions should be used for. (Think IllegalArgumenteException).
> Most of the time this indicates a programming error. Thus rather than
> putting in a try-catch block to handle the exception, the programmer
> should fix the mistake that led to the programming error in the first
> place. Assuming the programmer has fixed the mistake, there's no
> reason to catch the exception because it won't be thrown. And if the
> programmer's wrong, and they haven't fixed their mistake, then they
> should learn about it as soon as possible rather than having the
> exception get lost in an empty catch block added just to make the
> compiler shut up about an uncaught exception.

If the JVM could be configured with the new JDK 1.4 Logging to log
RuntimeExceptions and not blow the Thread, then I would agree
wholeheartedly. A service I've inherited recently came apart due to their
being a precondition that input must have length of 15 [as dictated in the
protocol, and in fact the physics of the transmitting objects] and would
IAE if anything else came in.

So of course the radio carrier carrying the transmitting objects message
had to prepend some spurious data and instant RuntimeExceptions at
production.

With this, I'm still not convinced by Bloch and Eckel that I should have a
more explosive system just because of the belief that developers can never
be beaten into not doing empty catch clauses.

NullPointerExceptions are a similar thing. I'm playing with a Business
Object tree design in which everything enforces the Null pattern and nulls
are illegal. At test/qa my Null patterns will throw exceptions when they
are used, however at Production they will merely log loudly.

Hen





Archive powered by MHonArc 2.6.24.

Top of Page