Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@f...> To: David Ornstein <davido@p...> Cc: xml-dev Mailing List <xml-dev@i...> 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@f... >Microstar Software Ltd. dmeggins@m... > http://home.sprynet.com/sprynet/dmeggins/ > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@i... the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@i... the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@i...) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
