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

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
Keywords