[jdom-interest] NoSuch*Exceptions in JDOM

[Jason Hunter]

Jim Rudnicki wrote:
> 
> Lurking here I notice everyone dividing into two camps. Let me offer a third
> 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."
> 
> >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 ignore.

Well said.  Eliminating the temptation to ignore returned null values
was one of the primary reasons we made the decision to throw.

> 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() ?

You know, I was halfway into proposing such a method when I stopped to
give it some more thought.  It lets you write code

if (elt.hasChild("foo")) {
  Element child = elt.getChild("foo");
}
else {
  // deal with none
}

which is debatably better to read.  The reason I wanted to think more
about it was that hasChild() would have to do an O(n) scan through the
children, then getChild() would have to do the same scan.  Course, we
could cache the hasChild() child trusting the user is pretty likely to
call getChild() if it returns true, but that's another piece of memory
every Element will have to hold.

-jh-