Re: [Sax-devel] URI's for errors

[David B. <da...@pa...>]

> > This strikes me a a very non-Java-like design...
> >[...]
> > Using identifiers of this nature would require lots of if-else-if logic
> > inside the catch blocks if you
> > wanted to treat the errors differently. 

Actually I think the primary use case (with XML level errors) is to
produce more specific diagnostics.  That was the context of the
original proposal; some folk also brought up the need to localize
diagnostics.  Error identifiers are necessary to solve those issues.
They also support idioms like "use ID as key to look up a handler",
which is a natural way to treat errors differently.

Do you really think that lots of separate catch clauses would be
easier to maintain than a table lookup?  I usually avoid having
very long try/catch/catch/.../finally clauses, since it's easy for
someone (else;) to put a subclass after its base, and break
something quite confusingly.  Also, from what I've seen, SAX
fault handling lives best in ErrorHandlers, not catch() clauses.


> >    In fact, this error code
> > style has always been one of my complaints about DOM and DOMException.
> 
> I agree here, I dislike the way DOM exceptions are signalled,

My own gripe there is that they're all unchecked exceptions, so I can't
automatically fence them into DOM-aware subsystems; they can infect
entire applications.  I haven't yet needed to write code that tests for
any specific DOM exception codes.


>     and it'd be
> unfortunate if SAX went the same direction. As Elliotte notes the 'Java way'
> to do this is to signal the type of error with, well, the type of the
> Exception!

One problem with that argument:  There are easily over a hundred
different types of (XML) error.  Applying that approach here means
easily over a hundred new classes, and corresponding complexity in
using and maintaining them.

And in fact, the "Java way" certainly uses the members of exception
classes to support specialized fault handling.  I can't see anything at
all contrary to the "Java Way" in having one of those members be an
an error ID.  Java has never been radically OO, although sometimes the
"JDK 1.0 way" (like over-synchronizing, long repudiated) probably
fueled such fires.


> Looking back I see that DavidB wasn't in favour of static strings for
> identifiers because adding errors means a software release. The same would
> be true of new exception classes, but I'd think that given the stability of
> SAX, and the well-defined error conditions in the REC, the need to
> add new types of errors ought to be infrequent.

For XML level things, maybe so -- but adding hundreds of new classes
would be a major change in the "API surface area", not to mention making
the interface much fatter.  People do use SAX in PDAs, after all, where
memory is relatively scarce.

- Dave