Patrick Dowler wrote:
> On Fri, 23 Jun 2000, you wrote:
> > I suggest a new method following the java.util.Properties pattern
> > meets the underlying need and solves your problem. Namely:
> >
> > public Element getChild(String aString, Object defaultValue)
> >
> > It does not throw a NoSuchElementException and can return
> > a null, "" or 0 as appropriate. -GreatOne--
>> This seems to go totally against what most people are trying to do. If
> you call getChild, you really want to know if the child was there or not.
> Having a default value returned doesn't seem too useful for anyone...
> correct me if I'm wrong on that :-)
>> For something simple like Properties, it makes sense. For a child
> element, you could be talking about a whole structure ( the "body"
> child of an "html" Element, for example).
>> Did this ever get resolved? What is the current standing of returning
> null vs. throwing NoSuchElementException from getChild? I got the
> feeling last week that we have not reached any consensus on this...
>> I'm still for a null return value.
> --
>> Patrick Dowler
> Canadian Astronomy Data Centre
It meets the need I had. I do not care whether the element is present
or not, I just want a value. I would use getChild(aString,"").getContent().
or getChild(aString,0).getIntContent().
I believe getChild(aString,null).getContent() exhibits the behavior you
want for strings. It returns a null value when the element is not present
and does not throw an exception.
However, if order to differentiate between a default value versus whether
the element was present or not, then methods would be needed to return a
class (i.e. Int vs int) so a null return was possible. For example:
getChild(aString,null).getWrappedIntContent().
It returns a null value when the element is not present and does not throw
an exception. If getIntContent() was used and the value was not present,
then an exception would be thrown.
I am off to vacation on a desert island, I will be back in a week.
---GreatOne--