[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] [XSLT 2] rescue

---

---

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

---