Top Description Methods
org.xml.sax

public Interface ErrorHandler

Known Direct Subinterfaces
com.sun.org.apache.xml.internal.serializer.SerializationHandler
Known Direct Implementers
org.xml.sax.HandlerBase, org.xml.sax.helpers.DefaultHandler, org.xml.sax.helpers.XMLFilterImpl, com.sun.org.apache.xml.internal.utils.DefaultErrorHandler, com.sun.org.apache.xml.internal.utils.ListingErrorHandler, com.sun.org.apache.xerces.internal.jaxp.JAXPValidatorComponent.DraconianErrorHandler, com.sun.org.apache.xerces.internal.jaxp.validation.DraconianErrorHandler, com.sun.org.apache.xerces.internal.util.DraconianErrorHandler, com.sun.org.apache.xerces.internal.util.ErrorHandlerProxy, com.sun.org.apache.xml.internal.dtm.ref.IncrementalSAXSource_Filter, com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM, jdk.xml.internal.ErrorHandlerProxy

Basic interface for SAX error handlers.

If a SAX application needs to implement customized error handling, it must implement this interface and then register an instance with the XML reader using the setErrorHandler method. The parser will then report all errors and warnings through this interface.

Warning

If an application does not register an ErrorHandler, XML parsing errors will go unreported, except that SAXParseExceptions will be thrown for fatal errors. In order to detect validity errors, an ErrorHandler that does something with error() calls must be registered.

For XML processing errors, a SAX driver must use this interface in preference to throwing an exception: it is up to the application to decide whether to throw an exception for different types of errors and warnings. Note, however, that there is no requirement that the parser continue to report additional errors after a call to fatalError. In other words, a SAX driver class may throw an exception after reporting any fatalError. Also parsers may throw appropriate exceptions for non-XML errors. For example, XMLReader.parse() would throw an IOException for errors accessing entities or the document.

Author
David Megginson
Since
1.4, SAX 1.0
See Also
org.xml.sax.XMLReader#setErrorHandler, org.xml.sax.SAXParseException

Method Summary

Modifier and TypeMethod and Description
public void
error(SAXParseException
The error information encapsulated in a SAX parse exception.
exception
)

Receive notification of a recoverable error.

public void
fatalError(SAXParseException
The error information encapsulated in a SAXParseException.
exception
)

Receive notification of a non-recoverable, fatal error.

public void
warning(SAXParseException
The warning information encapsulated in a SAX parse exception.
exception
)

Receive notification of a warning.

Method Detail

errorback to summary
public void error(SAXParseException exception) throws SAXException

Receive notification of a recoverable error.

This corresponds to the definition of "error" in section 1.2 of the W3C XML 1.0 Recommendation. For example, a validating parser would use this callback to report the violation of a validity constraint. The default behaviour is to take no action.

The SAX parser must continue to provide normal parsing events after invoking this method: it should still be possible for the application to process the document through to the end. If the application cannot do so, then the parser should report a fatal error even if the XML recommendation does not require it to do so.

Filters may use this method to report other, non-XML errors as well.

Parameters
exception:SAXParseException

The error information encapsulated in a SAX parse exception.

Exceptions
SAXException:
Any SAX exception, possibly wrapping another exception.
See Also
org.xml.sax.SAXParseException
fatalErrorback to summary
public void fatalError(SAXParseException exception) throws SAXException

Receive notification of a non-recoverable, fatal error.

As defined in section 1.2 of the W3C XML 1.0 Recommendation, fatal errors are those that would make it impossible for a parser to continue normal processing. These include violation of a well-formedness constraint, invalid encoding, and forbidden structural errors as described in the W3C XML 1.0 Recommendation.

API Note

An application must assume that the parser can no longer perform normal processing after reporting a fatal error and may stop by throwing a SAXException without calling ContentHandler#endDocument(). In addition, the parser cannot be expected to be able to return accurate information about the logical structure on the rest of the document even if it may be able to resume parsing.

Implementation Note

After invoking this method, the parser may stop processing by throwing a SAXException, or implement a feature that can direct it to continue after a fatal error. In the later case, it may report events on the rest of the document without any guarantee of correctness.

Parameters
exception:SAXParseException

The error information encapsulated in a SAXParseException.

Exceptions
SAXException:
if the application chooses to discontinue the parsing
warningback to summary
public void warning(SAXParseException exception) throws SAXException

Receive notification of a warning.

SAX parsers will use this method to report conditions that are not errors or fatal errors as defined by the XML recommendation. The default behaviour is to take no action.

The SAX parser must continue to provide normal parsing events after invoking this method: it should still be possible for the application to process the document through to the end.

Filters may use this method to report other, non-XML warnings as well.

Parameters
exception:SAXParseException

The warning information encapsulated in a SAX parse exception.

Exceptions
SAXException:
Any SAX exception, possibly wrapping another exception.
See Also
org.xml.sax.SAXParseException