W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > July 2007

Re: Catching errors

From: Rui Lopes <rlopes@di.fc.ul.pt>
Date: Tue, 10 Jul 2007 14:58:31 +0100
Message-ID: <46939087.5040507@di.fc.ul.pt>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Rui Lopes <rlopes@di.fc.ul.pt> was heard to say:
> | I'd like to propose a more flexible way to handle errors, in comparison to the
> | status quo.
> |
> | My proposal is a small addition to the p:catch element: an optional @code
> | attribute with the same semantics of p:error's code option. This would allow a
> | pipeline author to catch just a specific error, instead of catching any error,
> | handling it appropriately in situ. Other errors would be caught by outer
> | p:try/p:catch blocks.
> This is almost just syntactic sugar for a p:choose inside a p:catch.
> What's different is that it would allow "other errors" to percolate
> up. We have no mechanism for doing that.

Allowing "other errors" to percolate up is the key factor. With @code, a 
pipeline library author has the ability to control over which errors 
should be handled by the library itself or by library users. Imho, it's 
not a corner case.

With the status quo, the only way to emulate this would have to pass 
through the following imperfect hack:

     <!-- call a bunch of steps -->
   <p:catch name="foo">
         <p:pipe step="foo" port="error" />
       <p:when test="/err:errors/err:error[@code='err:XD0001']>
         <!-- handle the error appropriately -->
           <p:option name="code" select="/err:errors/err:error/@code">
             <p:pipe step="foo" port="error" />
           <p:option name="description" select="/err:errors/err:error">
             <p:pipe step="foo" port="error" />

Assuming this excerpt is correct (i'm not even sure about it - can I do 
that on the description option of p:error, i.e., multiple err:error 
elements passed as option), and despite its ugliness, this hack doesn't 
afford a transparent way to pass the same error to outter scopes, as 
err:errors/@name and err:errors/@type attributes would reflect the 
p:error, not the appropriate step that generated an error.

Again, with @code on p:catch, this could be specified as:

     <!-- call a bunch of steps -->
   <p:catch code="err:XD0001">
     <!-- handle the error appropriately -->

> I don't know. Someone's going to suggest p:finally if we do this.
> (Actually, it's already been suggested to me, but...)

I'm not sure if p:finally would be useful outside corner cases, but I'd 
give it a chance. Maybe an example would clarify this.

> | On a side note, should we define error codes for each step (both required and
> | optional ones), or leave it as implementation defined? I think it would be
> | somewhat verbose to describe them (e.g., all errors for XSLT 2.0), but it would
> | provide us a thinner control of pipelines -
> | and interoperable - using my @code proposal.
> We should probably define codes for the "obvious" errors in our
> standard components. I don't think we want to enumerate all the
> possible user errors though (e.g., all the things that can go wrong in
> an XSLT stylesheet).

Yes, I agree.

Received on Tuesday, 10 July 2007 13:58:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:43 UTC