RE: [XQuery] Error Handling ?

Xavier Franc>> This is a badly lacking feature in XQuery:
> >> AFAIK, there is no way to recover/catch a dynamic error after it
> >happens.
> >
> >> 1) introduce an error catching mechanism
> >
Paul Cotton >The WG considered adding this functionality to XML Query
and 
> decided to not add it to XML Query 1.0.
> >  
> >
> 
XF> I wonder whether the WG members have ever tried to write *real* 
> applications with XQ!
> Do they think it is acceptable that a query exits with a fatal error 
> just because
>   of an unsuccessful attempt to open a document ?

We did look very hard at this issue. We decided that it would be a
mistake to tackle error recovery before defining the update facility in
XQuery, which is likely to require introducing concepts such as
transactions and rollback. We do know that it's a gap; you can't do
everything in version 1.0.

In fact you can't do everything in version 2.0 either; we've tried to
tackle this in XSLT and haven't come up with a design that everyone
finds acceptable.

We took a look at all the dynamic errors that can be raised, to identify
those where there is no preventative action available to the programmer.
We found two such cases: errors in casting (e.g. converting a string to
a date), which we made preventable by adding the "castable" operator,
and errors in retrieving external resources using functions such as
doc(). The specification for doc() allows implementations a great deal
of freedom, and many implemementations are likely to provide mechanisms
such as the JAXP URIResolver hook to allow users to tailor the behavior.
A URIResolver can be used to recover from errors in retrieving a
document, for example the URIResolver can return a standard error
document containing information about the error.

We realize that a real try/catch, integrated with transactions and
rollback, is needed in the longer term, but we feel that the current
situation is acceptable for XQuery 1.0.

Of course, this is a personal response not a WG response.

Michael Kay

Received on Sunday, 1 February 2004 13:09:08 UTC