[jdom-interest] NoSuch*Exceptions in JDOM
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
>> 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