[jdom-interest] [Vote] NoSuchChildException

[Randall Parker]

On Thu, 13 Jul 2000 08:26:52 -0400, Elliotte Rusty Harold wrote:

>I still stick to this point. I found the benchmarks posted to be 
>thoroughly misleading and deceptive. They failed to take into account 
>the fact that far more often than not no exception would be thrown. 

Elliotte,

There are applications for which I can say from personal experience that that is simply not true. 

You've ignored my posts about relational databases. Yet they are the most relevant here. Lots of XML documents will be generated from relational databases. How will null field values be represented? 
Most likely by optional elements that don't get included. Well, null is a normal value (even though C.J. Date thinks it should be eliminated) in RDBMS table fields. The nullable fields in a relational 
database are very analogous to optional attribs and elements. 

When I read a database field from a JDBC result record and it is null (ie the real value isn't known or in existence) then JDBC does not treat that as an error condition. Neither should JDOM when it reads 
the same data from an XML document instead.

>Exception handling in Java VMs is designed, quite rightly, to be zero 
>cost in the case where no exception is thrown.

I think normal data values should not generate an exception. An optional value that is absent is logically the same as a value that is null. Its a normal case.

Allowing this to be a normal case may be bad. But the XML spec created that condition when it allowed optional values. 

>Maybe the real point of contention is that I think not getting 
>something you ask for by name is an exceptional condition, similar to 
>trying to open a file that turns out not to exist; whereas some other 
>posters seem to feel that it's quite natural that something they ask 
>for by name wouldn't be there. 

Its quite normal for it not to be there in commercial RDBMS implementations. Whether it _should_ be normal is another questoin. 

>That view just seems strange and alien to me. 

>As somebody else pointed out, if you really don't expect that 
>the child will be there when you ask for it, then what's needed is a 
>method to ask whether it exists.
 to ask whether it exists.

If you really don't know if the child will be there then you already have the problem that you need to write logic to handle the case where it is not there. However, requiring that users write try/catch is not 
going to guarantee that they write that logic. They can just do a bunch of gets in a try and then write an empty catch. 

Also, there is something else that you are missing: If a requested value is there then the place where that gets handled may not be where the get is gettng called. Let me give you an example: Suppose 
you are reading an XML document in order to stuff the results into an RDBMS. Well, you may well only care that the value is null when you go to write out your set of values to a record. And there you 
may never need to look at the value to see if it is null because you may pass it straight on thru to the JDBC driver as an argument to a setXXX() call.

My point is that some returned values that are null are just going to flow thru a lot of software layers as a null and be used as a null at some much later point. There is no exception/problem that has to 
be dealt with right there where you get the null. 

Its not an error condition. Null is just another value that data can be.