RE: rescue; error recovery facilities needed

I am personally sympathetic to this requirement.

We had an attempt to define try/catch functionality at the XPath level. The
attempt failed partly because people thought the language was getting too
big and complicated, and partly because XQuery has decided not to updates at
this version (there is a feeling that try/catch probably interacts with
transactions and rollback, and that it therefore needs to be designed with
update in mind).

I don't think these arguments should stop us doing a try/catch in XSLT.
Apart from deciding the precise syntax, the issues that we need to address
are:

(a) how does it interact with the option for implementations to recover from
certain errors?

(b) what information about the error is made available in the "catch" block
(and how)?

(c) what do we say about "rollback", i.e. about lasting effects of
instructions in the try block (for example, xsl:result-document).

I will ask for this to go on the WG agenda.

Michael Kay



> -----Original Message-----
> From: Tobias Reif [mailto:tobiasreif@pinkjuice.com] 
> Sent: 18 June 2003 15:49
> To: public-qt-comments@w3.org
> Subject: rescue; error recovery facilities needed
> 
> 
> 
> Hi
> 
> Here's a request for XSLT 2, possibly also applying to XPath 2 and 
> related technologies.
> 
> 
> Problem Summary:
> 
> Current drafts of XSLT 2 / XPath 2 don't provide error recovery 
> facilities. This current limitation results in various 
> problems: an XSLT 
> application can not finish it's job, even if it could 
> continue after the 
> error. The app should be able to deal with error if it can 
> handle it, so 
> that the transfomation can continue.
> 
> 
> Scenario, Problem Details:
> 
> The input document references a file, via facilities specific to the 
> input's language (not via generic mechanisms such as XInclude, XML 
> external entity references, etc).
> The transformation application handles this with the unparsed-text() 
> function; here's a snippet:
> 
> <xsl:template match="textdata[@fileref]">
>    <xsl:variable name="file_abs"
>      select="resolve-uri(@fileref,base-uri(/))"/>
>    <xsl:copy-of select="unparsed-text($file_abs,'utf-8')"/>
> </xsl:template>
> 
> If the path supplied by the fileref attribute doesn't point 
> to a file, 
> then my XSLT processor raises a fatal error [1], and aborts the 
> transformation. Especially in cases where there is no human 
> supervision, 
> eg when the whole thing runs on the server, this is inacceptable.
> 
> This is a very common scenario.
> 
> 
> Solution, Request:
> 
> Please add error recovery facilities [2] to XSLT 2 / XPath 2.
> 
> The syntax for the mechanism could look like this:
> 
> XSLT 2:
> 
> <xsl:do>
>    <xsl:try>
>      <xsl:copy-of select="unparsed-text($file_abs,'utf-8')"/>
>    </xsl:try>
>    <xsl:rescue>
>      <xsl:variable name="message">
>        <xsl:text>could not insert </xsl:text>
>        <xsl:copy-of select="$file_abs"/>
>      </xsl:variable>
>      <xsl:message>
>        <xsl:copy-of select="$message"/>
>      </xsl:message>
>      <xsl:comment>
>        <xsl:copy-of select="$message"/>
>      </xsl:comment>
>    </xsl:rescue>
> </xsl:do>
> 
> An analog mechanism might also make sense as addition to XPath 2.
> 
> http://www.w3.org/TR/xslt20/#dt-recoverable-error
> "An error that is not detected until a source document is being 
> transformed is referred to as a dynamic error. Some dynamic 
> errors are 
> classed as recoverable errors. When a recoverable error occurs, this 
> specification allows the processor either to signal the error (by 
> reporting the error condition and terminating execution) or to take a 
> defined recovery action and continue processing. It is 
> implementation-defined  whether the error is signaled or the recovery 
> action is taken. If the implementation does choose to take recovery 
> action, it must  take the recovery action defined in this 
> specification."
> 
> I need a way to specify the recovery action to be taken. No 
> matter what 
> the processor chooses to do in the absence of this user specified 
> recovery action (abort or recover); when a user supplied action is 
> present (xsl:rescue), all processors must carry it out if the first 
> action failed.
> 
> 
> Alternatives
> 
> There are various solutions specific to the problem described in the 
> scenario. They solve this specific problem, but don't address the 
> underlying general issue.
> 
> A function resource-exists() for example would solve the problem 
> encountered in the specific use case described above, but it 
> would not 
> help in all other cases where user supplied error recovery action is 
> required.
> 
> 
> Use Case:
> 
> See Scenario.
> 
> 
> Possible Issues:
> 
> The "rollback" issue mentioned in [3] should be solvable.
> 
> AFAICS, Rollback of the result tree should not be required.
> 
> One possible solution might be:
> 
> Any action contained in xsl:try is only carried out if the 
> complete contents of the xsl:try succeed.
> 
> If one or more action fails, then none of them are carried out.
> 
> They are simulated/attempted/tested first, without affecting 
> the result 
> tree. This can represent a performance penalty, but where reliability 
> and predictable program execution is of high importance, this 
> most often 
> is acceptable.
> 
> Then the actions contained inside xsl:rescue are carried out.
> 
> 
> Discussion:
> 
> Please also see 
> http://www.biglist.com/lists/xsl-list/archives/200306/threads.
html#00593


Tobi


[1]
http://www.w3.org/TR/xslt20/#unparsed-text
http://www.w3.org/TR/xslt20/#d0e16677
"[ERR119] It is a dynamic error if a URI cannot be used to retrieve a 
resource containing text. This is a recoverable error. The processor 
must either signal the error, or must recover by treating the URI as if 
it referenced a resource containing a zero-length string."

[2]
Analog to begin-rescue (eg in Ruby), try-catch, etc in other languages.

[3] http://www.biglist.com/lists/xsl-list/archives/200306/msg00614.html


-- 
http://www.pinkjuice.com/

Received on Thursday, 19 June 2003 13:01:13 UTC