SAX/Java: Exceptions -- Lets take it out

[Don Park]

Lets remove the exceptions from the picture.  Exceptions are nice but most
folks don't know what to do with them other than dump it to stderr or throw
up a dialog.  Since there is no 'retry' in Java, Exceptions are of minimal
use other than being a barking dog before an earthquake.  It is also causing
us a headache with no pleasant solution in sight and holding up the
schedule.

I propose that:

1. SAX application not be allowed to 'throw' exceptions.  Instread,
exceptions must be caught and handled within each method call (i.e.
startElement).  Exception can be ignored if they are non-fatal or reported
to the parser.

2. Parser can rethrow the reported exception once the application returns.

Don

-----Original Message-----
From: David Megginson <ak117 at freenet.carleton.ca>
To: David Ornstein <davido at pragmaticainc.com>
Cc: xml-dev Mailing List <xml-dev at ic.ac.uk>
Date: Friday, January 09, 1998 4:03 AM
Subject: Re: SAX/Java: Exceptions, Again


>David Ornstein writes:
>
> > 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.
>
>For those languages, the parser would invoke the warning() or fatal()
>callbacks to report an IO problem, and your handlers could set a
>status variable.  For all SAX implementations, any invocation of
>fatal() means that your document is probably corrupt, is not
>guaranteed complete, and should not be processed (except for
>error-reporting purposes).
>
>
>All the best,
>
>
>David
>
>--
>David Megginson                 ak117 at freenet.carleton.ca
>Microstar Software Ltd.         dmeggins at microstar.com
>      http://home.sprynet.com/sprynet/dmeggins/
>
>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)
>
>


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)