Project

Profile

Help

Bug #5356

closed

Fatal errors are reported as errors

Added by Octavian Nadolu about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2022-02-25
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

If I set an error handler using com.saxonica.ee.jaxp.SchemaFactoryImpl.setErrorHandler(ErrorHandler), the fatal errors are reported as errors on the error handler. The problem seems to be in the ErrorReporterWrappingErrorHandler, that forwards the fatal error as error.

I tested with Saxon 10.6

Actions #1

Updated by Michael Kay almost 2 years ago

Sorry for not responding to this sooner.

The JavaDoc for SchemaFactory says you can set an ErrorHandler, and that errors, warnings, and fatal errors are reported to the three methods on the ErrorHandler. However, it never defines exactly what conditions should be classified as errors, warnings, or fatal errors. The specification of the ErrorHandler interface describes these conditions in terms of the XML recommendation, and error conditions that may be found in XML documents, which are difficult to extrapolate to the description of error conditions found in the XSD specification. We've therefore had to do a lot of creative interpretation of the specs. One approach would be to "do what Xerces does", but that's difficult to discover. and in my view trying to achieve compatibility with another implementation, with no documentation on how it behaves, is a lost cause.

In Saxon 10/11 we moved to the uniform ErrorReporter interface for a number of reasons, including:

  • the difficulty of conforming to underspecified JAXP interface

  • the convenience of using a functional interface with a single method, allowing implementation as a lambda expression

  • avoiding the expense of creating an Exception object for conditions such as validity errors that should not be considered exceptional

The ErrorReporter interface doesn't attempt to distinguish fatal from non-fatal errors; errors that are truly fatal (in the sense that they cause schema processing to be abandoned) are signalled by throwing an exception, not by calling the ErrorReporter. The mapping from an ErrorReporter to the JAXP ErrorHandler interface is therefore imperfect, and we've done the best we can in the circumstances.

I propose to close this with no action: the product is working as designed.

Actions #2

Updated by Michael Kay almost 2 years ago

  • Category set to Diagnostics
  • Status changed from New to Closed
  • Assignee set to Michael Kay

Please register to edit this issue

Also available in: Atom PDF