SAX/Java: Exceptions, Again

[David Ornstein]

David Megginson wrote [09:20 PM 1/8/98 -0500]:
>I think that I've just answered my own question about Exception
>handling in the Java implementation of SAX.  There is no reason that
>the SAX frontend for each parser cannot pack exceptions from the
>callbacks into a container and unpack them for the top-level
>transparently -- that way, the parser can still have tight
>compile-time error checking, but application writers won't have to
>jump through hoops to throw exceptions to the top level.  
[clip]
>I still need to define what a SAX parser is allowed to catch and what
>it may pass through.  Here's a rough sketch:
>
>
>1) A parser must catch all of its own, internal exceptions (i.e. no
>   SAX parser should throw an exception that others do not -- this can
>   be managed in the SAX frontend if necessary).
>
>2) A parser may catch any exceptions derived from
>   java.io.IOException (that includes the networking exceptions), but
>   only if it is capable of resolving or working around the problem
>   corresponding to the exception; otherwise, it must throw it on
>   through to the top-level user code.
>
>3) A parser must pass all other exceptions up to the user code.

I like this a lot.  

One question:

If the parser is unable to open a file (let's say) I'm assuming that this
will cause a java.io.IOException to be thrown and in a fully Java system,
the parser might well ignore this and allow the application to catch it.
This means that there's no need to have any kind of return code coming out
of the Parse() function in the parser interface.  In thinking about this
for other languages, for languages that support exceptions, we're mandating
that the SAX implementations in those languages use exceptions also (since
there's nowhere for the return code and the return codes are no specified
as part of SAX).  And in languages that don't support exceptions, I'm at a
loss to say what we'd do.

I'm have a funny feeling I'm missing something here, so please help me out
if you see what I don't.

Assuming that my reasoning is right, I'd propose that we agree on
return-codes for the most common situations (yeah, I know that may be hard
to nail down).

David



================================
David Ornstein
Pragmatica, Inc.
http://www.pragmaticainc.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)