[jdom-interest] NoSuch*Exceptions in JDOM

[Petri Wessman]

On Wed, 12 Jul 2000 07:25:38 -0400, Elliotte Rusty Harold <elharo at metalab.unc.edu> said:

>> This approach is starting to have a small amount of appeal to me.
>> Instead of choosing to install "vi" or "emacs" maybe we should install
>> both.
>> 

Elliotte> I just really don't like this. It smells to me of Perl where
Elliotte> there's more than one way to do it (and generally several
Elliotte> dozen ways). I'd really prefer to keep the API smaller,
Elliotte> simpler, and easier to grasp.  I can go either way on the
Elliotte> null or exception, but whichever way we go I'd like to stick
Elliotte> with it.

Well, I don't think that allowing two different ways to access basic
optional data (or actually, allowing two different ways of
representing the "null" optional object), is inviting the Perl
methodology. What I see is that there are two mutual and *different*
use cases here, and trying to fit them both into one model is a
mistake.

One one hand, we have "naive" users who need exception policing in
order to prevent null pointer exceptions. On the other hand we have
the experienced (or semi-experienced) builders of real-world systems,
who are hurt, sometimes quite badly, by the mandatory use of
exceptions (both in the system performance and in the code clarity
case).

Now, you can naturally profile JDOM for "naive" users, but that should
be a concious decision, and be made with the knowledge that this would
make JDOM less of an ideal choice to professional users. Similarly,
you can profile JDOM to be a lightweight and efficient API that
conforms to good Java coding design, and leave the "missing optionals
throw exception" 'feature' out. This also should be a concious choice.

Now, in my opinion you can have both, by implementing two different
access methods. Otherwise you will have to choose between the two
options above, and follow each path where it leads. The current JDOM
access methods *do* *not* serve the professional Java XML community as
well as they (easily) could.

I would obviously like to be able to use JDOM in large-scale,
industrial projects without having to resort to hacked versions of
it. If JDOM wants to be a beginner-only API (as opposed to a
beginner-friendly API), then some changes are needed, as have been
discussed previously on this list.

All my personal opinions, of course, feel free to disagree :)

//Petri