Re: Catching errors

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:

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

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:

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


> 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.



Cheers,
Rui

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