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

Catching errors

From: Rui Lopes <rlopes@di.fc.ul.pt>
Date: Tue, 10 Jul 2007 01:36:52 +0100
Message-ID: <4692D4A4.6040908@di.fc.ul.pt>
To: public-xml-processing-model-wg@w3.org

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.

A simple skeleton example:

<p:try>
     <p:group>
         ...
     </p:group>
     <p:catch code="err:XD0001">
         ...
     </p:catch>
</p:try>



If such mechanism is allowed, then I would like to propose a small 
change to p:try's syntax to enable multiple p:catch elements. Authors 
would have a way to produce cleaner error handling markup by avoiding 
having to use a p:choose inside the p:catch to achieve the same effect.

A skeleton example:

<p:try>
     <p:group>
         ...
     </p:group>
     <p:catch code="err:XD0001">
         ...
     </p:catch>
     <p:catch code="err:XD0002">
         ...
     </p:catch>
</p:try>


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.


Thoughts?


Rui
Received on Tuesday, 10 July 2007 00:37:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT