Re: [xsl] What is best practice for dealing with errors in XSLT 1.0?

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>]

At 2010-04-07 10:42 -0400, Costello, Roger L. wrote:
> While processing an input document, my XSLT transform discovered an 
> error. What is the best way of dealing with that error?

I don't think there is a "best" way.

> One approach to dealing with errors is to sprinkle <xsl:message 
> terminate="yes"> elements liberally throughout the XSLT document. 
> But the behavior of <xsl:message terminate="yes"> varies from 
> processor to processor. That's not appealing.
>
> It would be nice if the XSLT transform could  generate two result 
> documents - one result document contains the "ordinary" output and 
> the other result document contains descriptions of errors that were 
> encountered during processing.

But that breaks the XSLT mould:  there is no control over the 
execution of the processor when acting on a source file with a 
stylesheet.  One processor might do the processing in parallel on 
multiple CPU's, assembling the individual result trees into the final 
result tree in the prescribed order, but chapters being processed 
would be completed in an arbitrary order because of the length of the 
chapter.  The "encountering" is not necessarily in document order.

> Alas, XSLT 1.0 does not provide the ability to generate multiple output files.

It does with the use of an extension, but the outputs are mutually 
exclusive: you have to finish one output file before starting another.

> What's your suggestion for dealing with errors?

I can get frustrated with always erroring-out on the first fatal 
error found, so in many stylesheets I do the following, in both XSLT 
1.0 and XSLT 2.0:

<xsl:variable name="error-message">
  <xsl:call-template name="check-fatal-errors-1"/>
  <xsl:call-template name="check-fatal-errors-2"/>
  <xsl:call-template name="check-fatal-errors-3"/>
  <xsl:call-template name="check-fatal-errors-4"/>
</xsl:variable>
<xsl:if test="normalize-string($error-message">
  <xsl:message terminate="yes">
    <xsl:value-of select="$error-message"/>
  </xsl:message>
</xsl:if>

... and in each case the fatal errors simply produce a text string of 
a fatal condition detected, adding that text string to the string 
being built up.

If none of the checks produced any strings, then my stylesheet 
continues running knowing that certain conditions have been checked.

But that, too, requires a pass of the information checking for errors 
then a pass of the information to produce your result.

Another tack that would support the "simultaneous reports" you want 
could be simply using <xsl:comment> to seed your result with the 
error messages and then grep'ing the result looking for your seeded string:

  <xsl:if test="something-bad-here">
    <xsl:comment>fatal: <xsl:value-of select="stuff"/></xsl:comment>
  </xsl:if>

... which would allow processing to run and when processing is over:

  grep "fatal:" output.htm

Or, an XML way would be seeding the result with namespace-qualified 
elements of your choosing:

  <xsl:if test="something-bad-here">
    <myerror:fatal ref="123"><xsl:value-of select="stuff"/></myerror:fatal>
  </xsl:if>

... and then when done write another transform that reads the 
combined document extracting the error reports into an error file and 
leaving the polished result without any error reports in it as a second output.

I hope this helps.

. . . . . . . . . . .  Ken

--
XSLT/XQuery training:         San Carlos, California 2010-04-26/30
Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
XSLT/XQuery training:                 Ottawa, Canada 2010-05-10/14
XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
Vote for your XML training:   http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal