[jdom-interest] NoSuch*Exceptions in JDOM

Dino Valente dino at 3dstockcharts.com
Mon Jun 19 10:52:22 PDT 2000

At 11:28 AM 6/19/00 -0500, you wrote:

 >Jim Rudnicki wrote:
 >> Lurking here I notice everyone dividing into two camps. Let me offer a 
 >> direction.
 >> Any function using the return value to return error codes I accept as bad
 >> design.  I thought we all learned this long ago.  A section from "Writing
 >> Solid Code" burned in my memory (but looked up, p91):
 >>   "Don't use confusing dual purpose return values--each output should
 >> represent exactly one data type.  Make it hard to ignore important details
 >> by making them explicit in the design."

Jim to the rescue!!! Thanks - I appreciate the reference, and I think
you have, among other suggestions, pointed out one of the fundamental
differences between Java and C - we don't return -1 (except indexOf ....
grr...) to indicate errors, as that is bad form ;-)

Does throwing an exception flly directly into this by aborting the routine 
altogether?  I think so. Imagine that all searching routines in the library 
followed this approach.

Maybe we should have another routine that returns null if the child is not 

 >> >From this, the correct design choice is:
 >> 1. So getChild() should always return a child or throw an exception.  Null
 >> is not a child.  Exceptions are hard to ignore.  null is too easy to 

How did you interpret that throwing an exception is acceptable from the 
quote you provided. The way I interpret the quote is that returning an 
exception is another value which adds to the argument that getChild should 
return null since null is a valid value for Element. Throwing an exception 
is not a good way to return a result. It should probably throw a RunTime 
exception (not an Exception that should be caught) since you are implying 
the precondition of the getChild is that the child must exist.

 >> 2. If the program does not know if a child is present, it should, must, or
 >> ought to be testing with:
 >> boolean hasChild( String s );
 >> Alas, there is no hasChild() ?
 >There's not, but on the strength of this email, I'm willing to put one

It would be nice if one were able to insert their own definition of Element 
or Document or Attribute when building the JDom classes so it is possible 
to add routines to the library that suits their needs/beliefs.


More information about the jdom-interest mailing list