[
Lists Home |
Date Index |
Thread Index
]
> > and try/catch.
>
> Ooh. Intriguing. We had a discussion about such extensions in the
> 4Suite mailing list a few years back. My own proposal was for special
> XSLT error templates that could "match" or trigger on error
> conditions,
> assuming a very simple XML vocab for XSLT error communication in the
> first place. Then there could be some sort of error mode so that
> explicitly scoped try/catch constructs were not necessary. Rather,
> simple heuristics would provide for matching current error and error
> mode to error template.
>
> Do you know of or have any references to any particular exception
> handling proposals from the XSLT 2.0 development process?
There were a number of iterations within the WGs on this. Try/Catch was
initially tackled as a joint item between XQuery and XSLT. Then XQuery
decided that it would be a mistake to define try/catch before defining
transaction semantics, which are part of the post-1.0 update proposal. The
XSL WG then looked briefly at various ideas for an XSLT-only solution,
either at the XPath level or the XSLT level, but it foundered partly because
of the difficulty of defining the semantics precisely enough, partly because
it's not clear how far one should go in terms of catching specific errors
versus general errors: in the end it probably didn't get in because no-one
was able to produce a really complete and convincing proposal, even though
the WG liked the idea in principle.
I do in fact have a user-written Saxon extension in this space waiting to be
integrated, but like many such contributions it contains code changes only,
no documentation or tests or design, so it's not all that useful. In the
meantime Saxon SA does contain a very simple saxon:try() pseudo-function:
see http://www.saxonica.com/documentation/extensions/functions/try.html
Michael Kay
|
