[jdom-interest] NoSuch*Exceptions in JDOM

[Patrick Dowler]

On Fri, 16 Jun 2000, you wrote:
> Actually, the chaining together with a NoSuchElementException tells
> you that the XML document was malformed, which may be enough in most
> cases.  If, on the other hand, the application needs greater control
> of the error, then it can look at each step in the chain (rather than
> doing a chain).
> 
> The error message:
> 
> try {
> 	getChild...getChild...getChild...
> }
> catch ( NoSuchElementException e ) {
> 	System.err.println( "Element missing in XML document: " +
> e.getMessage() );
> 	...
> }
> 
> is extremely useful.  It tells the user exactly what is wrong
> with the document.  It is most likely the case that the application
> does not need to know anything other than this to do the appropriate
> error handling (document is invalid, so don't process it).
> 
> Also, it is useful to do the chaining when you know that the document
> is already valid.  My point is that this is far more useful than
> throwing a NullPointerException through accessing a null pointer (which
> may be interpreted as a bug somewhere inside getChild).

I agreed that NullPointerException was dodgy at best because it tells you
very little about what happened (and is generally indicative of a programming
error rather than an error in the input/document). This is all a sidetrack
about usage and not design per se...

What we are arguing here is really whether indicating a missing
child should be done via returing null or throwing an exception. The point
has been made many times that JDOM  should work the way Java "works" and
not the way XML "works":

	* In XML, a missing child you think should be there is an error. 

	* In Java, a missing child in a container (Elements are containers) 
	is not an error condition, as shown in my example of
	java.util.Map.get().

If we want JDOM to work naturally in Java, then getChild should return
null.  If we are particularly keen to have JDOM support ONE usage style
(chaining getXXX calls together) at the expense of forcing people to
catch exceptions in non-exceptional conditions, the so be it.  Let's just
be clear what we are actually arguing about. An exception means "there
is nothing I can do and there is no sensible return value, so I have to abort".
This is not such a case (null is a sensible return value).

Personally, I am -1e6 on using exceptions for things that are not exceptions.

-- 

Patrick Dowler
Canadian Astronomy Data Centre