[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Error Reporting (question 4 of 10)
David Megginson wrote: > I don't agree that we > should automatically use exceptions for fatal errors, because > sometimes it will be useful to try to report more than one error at > once -- the Java XmlAppBase class will throw an Error by default for > fatalError, however. ... > Agreed: good error reporting is out of scope. ... > In the end, we are not looking to provide the kind of detailed error > reporting that NSGMLS does -- SAX is a production interface, not an > authoring one, and needs only give a very rough indication of why it > is giving up. Normally, then, the author should turn to a validating > parser for full debugging support. If you're not aiming to provide detailed error reporting suitable for authoring, why would you need to report more than one fatal error? For a production interface, throwing an Exception should be quite sufficient. It would not be appropriate to throw an Error: errors are for things that applications should not normally try to catch. Instead we should have something like public class XmlNotWellFormedException extends java.io.IOException { private String url; private int line; public XmlNotWellFormedException(String message, String url, int line) { super(message); this.url = url; this.line = line; } public String getURL() { return url; } public int getLine() { return line; } } I feel pretty strongly that the right way to handle fatal XML errors in Java in a production-oriented interface is with an exception and that SAX needs to define an exception to cover fatal XML errors. The exception should extend IOException so that it works with the java.net.ContentHandler stuff. A parser that wants to provide more detailed information can simply derive a class from XmlNotWellFormedException, and an application can catch that and use the additional parser-specific information if it's available. Having the stub class create the exception doesn't work well because the stub class (being parser independent) can only create an XmlNotWellFormedException and not the richer parser-specific exception that extends it. A reasonable solution would be to have: void fatalError(XmlNotWellFormedException e) throws IOException; in the interface, and then void fatalError(XmlNotWellFormedException e) throws IOException { throw e; } in the stub. James 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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|