Subject: RE: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++ From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Fri, 25 Jan 2008 10:30:45 -0000 |
Firsly, xsl:message terminate="yes" is I think semantically equivalent to error(); both cause the transformation to fail with a dynamic error, and to produce no output. (Though XSLT states that any output produced using xsl:result-document calls prior to termination may or may not be available on completion.) You seem to be looking for some kind of termination that "closes and tidies everything up" before dying. By that, I assume you mean that you want some kind of partial output to be available to the calling application? I wonder if you could explain this idea more clearly - are you thinking perhaps of some kind of model where everything on the call stack returns an empty sequence to its caller, bypassing all type checking, and then makes the half-written result tree available to the application? What would be the use case for this? Clearly, one of the rules for xsl:message and error() is that order of execution is unpredictable, and therefore it's unpredictable how far execution has proceeded at the time of termination. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: ac [mailto:ac@xxxxxxxxxxxxx] > Sent: 25 January 2008 09:56 > To: lists@xxxxxxxxxxxx; xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: [xsl] manage errors and terminations, child thread > of Re: [saxon] Too many attribute value templates? ++ > > Hi Florent, > > I find xsl:message with @terminate useful, yet, somewhat > radical. It might be nice to also pass it a closure > function/template(/or selector > of) as attribute/child, to possibly clean things up, in > various ways, before dying. error() is fine two but it is > just even a little bit more radical. error() may also benefit > from the additional closing selector. > > Still, the current xslt options are fine, as an application > that manages errors, leaves @terminate mostly for testing & > debugging, as well as for that application's error management > service, after closing and tidying everything up, ready to > die. Since tests and debugs may be harder to structure ;-}, > and since in such an application, one only shuts down once, > error() is probably more useful in other context. > > Although interesting, I have some doubts on how much of this > is directly related to Saxon. Would you agree that it might > now more be relevant on the xsl list, and allow me to throw it there? > > Thanks. > Cheers, > ac > > > > If you want a run-time error in this case, you can simply use > > xsl:message with @terminate or xsl:sequence with error(). I feel > > error() is not used often while this is of great help to check some > > assumptions, while developing and even in production... > > > > Regards, > > > > --drkm
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] manage errors and termination, ac | Thread | RE: [xsl] manage errors and termina, Owen Rees |
Re: [xsl] How to prevent spaces in , David Carlisle | Date | Re: [xsl] Filtering new tags, Joe Fawcett |
Month |