[jdom-interest] [Vote] NoSuchChildException

[Petri Wessman]

On Wed, 12 Jul 2000 13:51:36 -0400, Elliotte Rusty Harold <elharo at metalab.unc.edu> said:

Elliotte> -1 on returning null

Elliotte> You asked for a reason for a -1 vote so I'll give you mine. I was 
Elliotte> initially undecided, but when I actually looked at the code people 
Elliotte> were proposing for returning null it struck me as completely the 
Elliotte> wrong way to do anything.

I guess that you knew that this would provoke response from people :)


Elliotte> I get a very strong feeling of "We don't need no stinking
Elliotte> exceptions" in this thread; and I don't think it's a
Elliotte> rational response. I think they're a lot of programmers out
Elliotte> there who don't like exceptions, never really understood
Elliotte> them in the first place, and certainly don't feel
Elliotte> comfortable with them now. I see this all the time in the
Elliotte> students I teach, and one of the things I insist on in my
Elliotte> classes is making sure my students use exceptions whether
Elliotte> they want to or not.

This is getting a bit thick. First of all, I'm an experienced,
professional Java programmer (among other things), and I've both coded
Java and read about it extensively. I also love exceptions, threads
and other advanced features that Java provides. OTOH, it's possible to
use exceptions in inappropriate ways, just as it is possible to use
multihtreading in inappropriate ways.

New Java programmers either never throw exceptions (they are an alien
concept to them) or they go overboard and use exceptions for "return
values" in the normal operation of a method. Likewise, new Java
programmers easily get carried away with threads, spawning zillions of
threads and grinding the JVM to a halt.

No program language or API can sustitute for intelligent design, or
totally stop bad design.

Now, as I read your text above, you're essentially claiming that the
people on this list who oppose throwing exceptions in certain JDOM
methods "have never understood exceptions and don't like them". Wrong,
plain and simple. I'm opposing exceptions in these cases precisely
because I *do* understand them, and IMHO know when to use them and
when not to use them.

Do you?


Elliotte> I think they're a lot of programmers who don't want to have
Elliotte> to think about how to handle exceptions. Returning null lets
Elliotte> them ignore the problem and pretend it's gone away. All
Elliotte> claimed benchmarks aside, that's its biggest attraction.

Putting benchmark references in the form of "claimed benchmarks"
implies that the results and/or the claimers or the results are
suspect, which I find a bit insulting. There are numerous sources for
the fact that throwing exceptions in Java is very expensinve compared
to return values. These sources are supported by my quick benchmarks,
such as they are. If you knew the design of the typical JVM, it should
be obvious to you why exceptions are comparatively slow in Java.

You're making the claim that programmers who do not like exceptions in
this case are, basically, incompetent and want exceptional situations
to just go away. Hello? Have you read *anything* or the previous
posts, past your own preconceptions?

I'm getting the picture that you don't really understand Java
exceptions, and the way the language designers intended them to be
used - a lot of the things you are claiming are plain *wrong*.


Elliotte> Throwing the exception is the right thing to do. It requires
Elliotte> programmers to handle the case where the element isn't
Elliotte> there. The reason checked exceptions exist is precisely
Elliotte> because programmers can't be relied on to check error codes
Elliotte> and return values. That's exactly what we're dealing with
Elliotte> here. Whichever way the vote goes, this method will cause
Elliotte> exceptions. The only question is whether these will be
Elliotte> NoSuchChildExceptions that will be caught in a relevant
Elliotte> catch block, or uncaught NullPointerExceptions that bring
Elliotte> the whole program down.

What?

Throwing the exception in this case is the *wrong* thing to do. Not
(only) my opinion, but the opinion of every serious Java book and
article I've read, starting from Gosling himself. Now, you may wish
that Java exceptions are something they are not, but that won't change
the situation. In *Java*, throwing exceptions in non-exceptional
situations is bad design. I really hope you're not teaching stuff like
this to your students.

"Programmers cannot be relied to check error codes and return
values". This sentence is revealing.

You cannot *force* good design by language or API features. You can
encourage it, but you cannot *force* it. With the current JDOM, a bad
programmer will just wrap everything in one huge try {} catch
(Exception) block and be done with it. You're trying to use bad Java
design (using exceptions for a normal return value) to catch beginner
mistakes.

Your methodology may be ok for a "beginning Java" workshop, but we're
not there now. You're advocating broken Java design, clear and
simple. As a fairly competent designer, I do not like that in the
least, especially when you veil you opinions in immuendo about "us"
not understanding the language and wanting the easy way out.

//Petri, slightly pissed off