Bug #4376

xsl:message content is not available within xsl:catch as $err:value

Added by Michael Kay about 2 years ago. Updated about 2 years ago.

XSLT conformance
Start date:
Due date:
% Done:


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


The specification requires that when the error triggred by an xsl:message instruction with terminate="yes" is caught, the message body should be available within the xsl:catch as the value of $err:value.

This appears to be unimplemented and untested.

I have added a test case message-0501.

Reported by AirQuick on the saxon-help mailing list at sourceforge.


#1 Updated by Michael Kay about 2 years ago

This is tricky to implement because xsl:message output is sent to a user-supplied message listener, and it's only actually assembled into an in-memory tree if the message listener chooses to do so.

Even if we try to implement it only within the default message listener, we still have the problem that it requires extending the interface to the message listener so that the assembled tree can be retained.

This leaves the option (not especially attractive, but viable) of having xsl:message (if terminate=yes) first construct the message as an in-memory tree (which can be referenced from the exception object picked up by xsl:catch), and then replay this tree to the message listener.

#2 Updated by Michael Kay about 2 years ago

  • Status changed from New to In Progress

Fix implemented for 9.9, still needs to be applied to trunk.

Note that Saxon inserts a processing instruction into the xsl:message document containing the error code and the location of the xsl:message instruction. This is convenient, but not strictly according to spec.

#3 Updated by Michael Kay about 2 years ago

  • Category set to XSLT conformance
  • Status changed from In Progress to Resolved
  • Priority changed from Low to Normal
  • Fix Committed on Branch 9.9, trunk added

#4 Updated by O'Neil Delpratt about 2 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release added

Patch committed to the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF