Re: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++

Subject: Re: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++
From: Florent Georges <lists@xxxxxxxxxxxx>
Date: Fri, 25 Jan 2008 16:26:03 +0100 (CET)
Owen Rees wrote:


> --On Friday, January 25, 2008 10:30:45 AM +0000 Michael
> Kay wrote:

> > 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?

  I wonder too.  Especially because...

> > 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.

  For debugging purpose, I can see the interest of being
able to see the result of what was evaluated so far.  The
Saxon's -T option has saved me debugging nightmares in this

> Perhaps a 'throw' to a try/catch of some kind is what is
> intended.  There was a discussion of 'try' at the
> beginning of this month which would be worth looking at
> for those who did not see it:

> The idea of closing and tidying up makes me think of the
> kind of things I would put in a 'finally' in Java or an
> 'unwind-protect' in Lisp but those are all to do with
> undoing side-effects and carrying on. It is not clear what
> it would be for when there are no side effects

  Exactly the same way 'unwind-protect' is defined in Common
Lisp IMHO.  The syntax can be different but the ideas are
the same: 1/ you must identify a part of the code to be
protected (catch or unwind-protect in Common Lisp or try in
Java), 2/ if this part complete successfuly its value is
used, 3/ if not you have to provide another value (throw in
Common Lisp or something like the catch in Java).

  But the value of the whole expression is either the whole
value of the protected expression, or the alternative value
in case of error, but never part of one or another (side
effects apart).



Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

Current Thread