On Sun, Jun 18, 2000 at 01:07:08PM -0700, Jim Rudnicki wrote:
> Stand your ground. getChild should not be a function that either tests for
> non-existence or retrieves. Returning null is just like the nightmarish new
> operator in C++. We all ASSERT every single new right? sure ya do. Nobody
> ever runs out of memory, why bother testing for null.:)
As someone else pointed out, "null" is in the range of valid values
for the type "reference to object". Essentially, it's saying "the
object you requested is the nonexistent object."
Which brings up an interesting alternative nobody's proposed yet.
Probably because it's so retarded and we should definitely not use it,
but here it is:
Have getChild("missing") return the empty element!
This would be an actual object instance, but with no name, no content,
and no children. It's a singleton, so you could compare to it like
you compare to null; but it can actually be called, so
getChild("missing").getContent()
would not throw a NPE (but might return null from getContent()).
The following would also succeed:
getChild("missing").getChild("alsomissing").getChild("waymissing").getContent()
Hmmm, I'm actually developing a sort of fondness for this benighted
solution...
> For the old schoolers, give em this:
>> package org.jdom.not; // :)
>> class OldElement extends Element {
> Element getChild( String strTagName ) {
> Element elRet;
> try {
> elRet = super.getChild( strTagName );
> }
> catch( NoSuchElementException x ) {
> elRet = null;
> }
> return eRet;
> }
> }
Was this serious? This won't work because Element.getChild declares
NoSuchElementException so we'd have to catch it anyway, even though
it's never thrown.
--
Alex Chaffee mailto:alex at jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/