Michael Kay wrote:
> Unfortunately there is no try-catch in XPath 2 or XSLT 2.
This indeed is unfortunate. Luckily those specs are still drafts, so I
hope that the final versions will satisfy this important requirement
(which you seem to share).
> We debated putting one in, but people felt it was a bridge too far.
> People were particularly concerned about defining exactly what state
> the system was in if an error was trapped and ignored,
I don't want to ignore it, but instead I must be able to deal with it.
If my XSLT application, running without supervision (eg on the server),
gets fed a document which references a non-existent file, then my
application must be able to deal with that; It is unacceptable to abort
the whole transformation. Since I'm not aware of any facilities to test
for the existence of files (validity of paths/URIs), I need a way to
recover from the currently unfortunately fatal error raised after a
failed unparsed-text().
> for example, should
> it effectively be required to do a "rollback" of the result tree.
AFAICS, this question does not arise for the type of scenario I
describe. Since it probably is a very common use case, and since there
probably are many more use cases where error recovery facilities are
needed and the rollback question does not arise, I suggest to add those
facilities.
The rollback issue can be dealt with in cases where it's an issue; if
there is no solution, then those cases can not have recovery facilities.
XSLT 2 / XPath 2 should offer error recovery facilites, for cases where
it makes sense and is feasible to specify. They are crucial, and are
found in many if not most programming languages.
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list