[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Michael,
I appreciate your comments:
[By the way:
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] Java exception handling in XSLT is possible (and darn useful!)
Subject: Re: [xsl] Java exception handling in XSLT is possible (and darn useful!) From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 03 Dec 2002 10:09:22 -0500 |
Hi Michael,
I appreciate your comments:
I think that what's really needed is a mechanism that handles all dynamic errors, not only those that come from extension functions.
clearly my ex:try / ex:catch element is specific to catching Java Exceptions. However, as it turns out, by catching anything that matches a TransformerException, I can actually catch any dynamic errors (as long as the XSLT processor is Java-based of course ...)
We spent some time trying to define a general try/catch mechanism in XPath 2.0 and decided to leave it out (influenced for once by the clamour to keep the language simple).
[By the way:
I'm not quite sure why XPath and not XSLT. I probably don't have the correct understanding of their relationship, but I'm afraid there is more and more functionality hidden in XPath with its special syntax. To me that's counter-intuitive. I think the big advantage for XSLT is the old LISP thing: your programs are my data! With more and more functionality stuffed in XPath I loose the ability to easily access program structures as data. So, I'd rather see flow control features in XSLT rather than in XPath.]
Some of the difficulties in specifying and implementing a general try/catch are:
* When you catch an error, do you rollback all changes to the result tree made by that try block? If not, what guarantees do you have about the state of the result tree after the catch?
That's a problem, yes. I do not roll-back right now, and that's going to be the first wall I'll hit my nose on once I am getting more serious with using my exceptions. One way of solving this would be to make the ex:try buffer the result tree and then emit it at once as the ex:try block is finished. It doesn't sound like hard to do, you could probably do it in a few hours (since you know Saxon) and I could do it in 24 hours. It's on top of my Saxon todo list now.
* Is lazy evaluation allowed to trigger errors inside the try block when evaluating constructs that appeared textually outside it, and vice versa?
I'm not sure I comprehend the question. I'd say the only effects that I would care for is the result tree constructed inside the try block. You aren't talking about side-effects of evaluations, are you? With your saxon:assign extension, you could definitely get unpredictable results. I would not want to deal with the problem of rolling back assign transactions against variables in scope beyond the try-block. Besides saxon:assign, I can of course see my post:message or any other side-effective calls to extensions be involved. I guess it's up to the programmer to manage their transactions, that's an issue regardless of whether there's exception handling or just on-error-quit-everything behavior.
* How does try/catch interact with the mechanism allowing processors to recover from dynamic errors?
I don't know those recovery mechanism in detail. I suppose that if you have a try block that sits on the call-stack between the source of the error and the next system-builtin recovery checkpoint, then you handle the error and the system will never see it. If a system checkpoint is between the source of error and thr try block, the try block will never see the error. Question is, should the standard say where system's dynamic error checkpoints should be located? Probably yes.
* How does try/catch interact with the JAXP mechanism for notifying errors to an ErrorListener?
I'm not doing anything in that regard. Perhaps out of ignorance. I could imagine user-modifiable logging might be nice may be using an attribute on <ex:try logging="yes"> or so, but other than that, I think the guy who catches exceptions can handle these things manually.
Thanks for your consideration. And as always, thanks for XSLT and Saxon. [It's only because of XSLT (and using Saxon) that I came to believe in this whole XML-fad.]
regards, -Gunther
-- Gunther Schadow, M.D., Ph.D. gschadow@xxxxxxxxxxxxxxx Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistant Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Java exception handling i, Michael Kay | Thread | [xsl] Doing HTTP/POST from XSLT is , Gunther Schadow |
RE: [xsl] Doing HTTP/POST from XSLT, Robert Koberg | Date | Re: [xsl] Borders between columns, W. Eliot Kimber |
Month |