[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX: Error Reporting (question 4 of 10)

  • From: James Clark <jjc@j...>
  • To: xml-dev Mailing List <xml-dev@i...>
  • Date: Sun, 04 Jan 1998 11:26:56 +0700

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)
    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.


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...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.