Support #4633
closed
Format of error messages, saxon command line
0%
Description
Dear Saxon Team and Community We're using SaxonEE9.9N using the command line. For our purposes, we would like to write a small parser to handle error messages created by Saxon. To do so, it would be great to have a summary or some list explaining the format of the error messages.
Currently, when we call the saxon xslt engine via command line, we get a list of errors, e.g.:
Static error in xsl:variable/@bla on line 10 column 95 of grips2webwitherrors4.xsl: XTSE0090: Attribute @bla is not allowed on element xsl:variable Static error at xsl:variable on line 10 column 95 of grips2webwitherrors4.xsl: XTSE0010: Element must have an @name attribute Static error at xsl:template on line 560 column 34 of grips2webwitherrors4.xsl: XTSE0500: xsl:template must have a name or match attribute (or both)
I'm now interested in the general description of the error messages, in particular the first line of each error message. For example, does the first line always start with "Static error"? Do all errors return a line and a colum? Are all error messages based on two lines? I'm aware of the Saxon error codes (https://www.saxonica.com/html/documentation/javadoc/net/sf/saxon/trans/SaxonErrorCode.html) and the W3 error codes (https://www.w3.org/2005/xqt-errors/) which are returned by the engine in the secon line of the error message (e.g. XTSE0010: ...). However, I could not find any information on the format of the first line of the error message (e.g. Static error in/at ...).
Please let me know if my request is unclear. Any help would be highly appreciated. Thank you very much for your help!
Updated by Michael Kay almost 4 years ago
The information that goes into the error message is provided in a more structured form in the object that's passed to the ErrorListener or ErrorReporter. There are significant differences here between 9.9 and 10.0, designed exactly for the kind of scenario you are describing, so I would suggest not investing too much effort on 9.9 since it will need to be re-done for the later release.
Your particular example describes a static error in XSLT, and of course that's only one possible scenario; we've also tried to move towards greater consistency between the various APIs e.g. for XSLT, XQuery, and XSD processing.
In 10.0 the principal interface is the ErrorReporter, which has a single method:
void report(XmlProcessingError error);
which makes it easy to supply an ErrorReporter as a lambda expression, e.g. in XsltCompiler.setErrorReporter(). This new interface also makes the break from the JAXP ErrorListener where errors always had to be constructed as Exception objects, which involves quite unnecessary overhead. There are several different implementations of XmlProcessingError, and if you're taking this seriously you might want to do more than access the standard properties available in the interface (getErrorCode(), getLocation(), etc) and look into what's available from some of the implementing classes.
The standard ErrorReporter used on the command line simply formats up the information held in the XmlProcessingError object. I'd strongly encourage you to start with the structured information, rather than trying to extract it by parsing the formatted message (which is liable to change between releases). Of course you might well want to use the Java code of the StandardErrorReporter as guidance it's in package net.sf.saxon.lib.
One caveat is that the actual error messages are only exposed as strings. For example, the message "Attribute @bla is not allowed on element xsl:variable" is supplied as a single string, not as a structure containing the template ("Attribute %s is not allowed on element %s", "@bla", "xsl:variable"). That's not ideal if what you're trying to do is to localise the messages; but it's still a big step forward.
Updated by Ralph Stoop almost 4 years ago
Thank you very much for your fast and detail answered. Indeed, the ErrorReported seems to be the best way to further prcosess error messages in a structured way as we plan to do. Many thanks again.
Please register to edit this issue
.