Project

Profile

Help

Bug #1849

closed

ValidationException reported to ErrorListener even if in try/catch

Added by Michael Kay almost 11 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Schema-Aware processing
Sprint/Milestone:
-
Start date:
2013-07-20
Due date:
% Done:

0%

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

Description

Reported by Roger Castello on saxon-help list.

MHK response:

What's happening here is that validation errors are reported to the ErrorListener immediately (resulting in an error message), even though the error is subsequently caught. The transformation actually runs to successful completion, with the desired output, despite reporting the errors.

Changing this is tricky, because it conflicts with the requirement to be able to report multiple validation errors, especially when validating result documents. If you change the source document so that multiple ISBNs are invalid, you'll see that several errors are reported, unlike other dynamic errors where only one error gets reported. I'll have to think about the best way forward here.

The current behaviour, if not ideal from a usability perspective, is in this case conformant with the spec. However, W3C has made some recent (not yet published) refinements to the try/catch spec which will require Saxon changes in this area - specifically, validation errors can only be caught at the level of the instruction that requests validation, not at the level of the instruction which generates or discovers invalid content. So there's going to have to be some rethinking anyway. At the same time, for 9.6, I'm looking at making changes to the ErrorListener interface to move away from its use of the JAXP TransformerException; JAXP is becoming increasingly peripheral to Saxon with its design basis in XSLT 1.0.


Related issues

Related to Saxon - Bug #1872: doc-available() fails with error on XML parse errorClosedMichael Kay2013-08-27

Actions
Actions #1

Updated by Michael Kay almost 11 years ago

It is reported that oXygen produces no output file if an error has been notified to the ErrorListener.

Actions #2

Updated by Michael Kay over 8 years ago

  • Status changed from New to Closed
  • Priority changed from Low to Normal
  • Fixed in version set to 9.7

Reporting of validity errors has changed considerably in 9.7: instead of going to the ErrorListener, they now go to an InvalidityHandler. One of the main motivations was to report these errors without creating Exception objects, which is expensive (the JAXP ErrorListener interface demands exceptions). The default StandardInvalidityHandler still logs messages as soon as an invalidity is detected (even within a try/catch) but no exception is signalled until the instruction that initiated validation fails.

I'm going to close this because I think that the current behaviour is adequate. One could envisage improvements (for example the ability to notify the InvalidityHandler in some way of entry/exit into try/catch blocks) but they would add a lot of complexity.

Please register to edit this issue

Also available in: Atom PDF