[jdom-interest] NoSuch*Exceptions in JDOM

Dehar Rohit rohit_dehar at yahoo.com
Mon Jun 19 08:27:35 PDT 2000


support:

Returning a null is more java-like and thats what JDOM is intended to
be. The thingy coming nearest to getChild() is java.util.Hashtable's
get() method (it returns the value to which the specified key is
mapped in this hashtable). It doesn't throw a No*Exception, plainly
returns a null if the key is not found.

plus:

its easier to check nulls than an exception every time. i'd
personally prefer null returns for xpath type support too (is that
too early to talk of xpath?).

Rohit Dehar

--- Jools Enticknap <jools at jools.org> wrote:
> 
> 
> On Sun, 18 Jun 2000, Jason Hunter wrote:
> 
> > 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.
> 
> During my initial thought, prior to writing my initial post I
> wondered
> about this, but after refreshing myself with the code I realized
> that in
> the success case it would be 2 O(n) scans through the children
> which I
> thought was a bit heavy, although caching would resolve that as
> long as
> no add/delete/has Child calls to another Element name were made
> prior to
> getChild being called.
> 
> But to me this all seems like a large hammer on a small nail, lets
> take
> the above example and nullify it.
> 
> Element e = elem.getChild("foo");
> if ( e != null ) {
> 	// Do something with e
> }
> else {
> 	// Do something else.
> }
> 
> Looks like it does the same, but with much less overhead. 
> 
> Don't get me wrong, I'm not shooting the hasChild() call down, I
> think
> it's a good idea, and I like the ability to check on the presence
> of a
> child before I try to get it, it's just that I think if we want to
> make it
> efficient caching is required, much like what has been done with
> getContent(). 
> 
> But it all adds weight to what is a nicely lightweight XML
> implementation
> which already does what is required.
> 
> <suggestion>
> 
> 1) Drop the NoSuch*Exceptions.
> 2) Return nulls, when the 'thing' you were looking for is not
> there.
> 3) Add the hasChild() call for those who don't want to check for
> null, but
>    add a JavaDoc comment stating the overhead of using this instead
> of 
>    null.
> 
> Adding the hasChild is a no-brainer, gets rid of the Exception and
> returning null helps the CPU restricted people get the job done
> quicker
> :-)
> 
> </suggestion>
> 
> --Jools (who's now off the fence)
> 
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com


=====
Rohit Dehar
Perot Systems
1 813 261 8936 (W)

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/



More information about the jdom-interest mailing list