xml-dev - Re: SAX: Error Reporting (question 4 of 10)

[James Clark <jjc@jclark.com>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)