This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We briefly touched on the subject of dynamic errors in evaluating an accumulators today, and it occurred to me that the spec has very little to say on the topic. Since accumulators are evaluated "in the background", it is not clear how a dynamic error should be handled, or whether it can be caught. I propose that a dynamic error that occurs while evaluating xsl:accumulator/@initial-value or xsl:accumulator-rule/@select should (only) cause a "subsequent" call on accumulator-before() or accumulator-after() to fail with (the same) dynamic error. In other words, the error is "held back" until the next time the accumulator is referenced (and by implication it goes unreported if the accumulator is not subsequently referenced). This fits well with a lazy evaluation strategy. If an accumulator is evaluated in a parallel thread to the main processing then the accumulator thread must hold on to the error until the time comes to report it. Dynamic errors become capable of a predictable try/catch behaviour.
Subject to WG approval, I have added the following text to resolve this: <div3 id="errors-in-accumulators" diff="add" at="T-bug29813"> <head>Dynamic Errors in Accumulators</head> <p>If a dynamic error occurs when evaluating the <code>initial-value</code> expression of <elcode>xsl:accumulator</elcode>, or the <code>select</code> expression of <elcode>xsl:accumulator-rule</elcode>, then the error is signaled as an error from the next call on <function>accumulator-before</function> or <function>accumulator-after</function> that references the accumulator. If no such call on <function>accumulator-before</function> or <function>accumulator-after</function> happens, then the error goes unreported.</p> <note><p>In the above rule, the word <term>next call</term> is to be understood in terms of functional dependency; that is, a call to <function>accumulator-before</function> or <function>accumulator-after</function> signals in error if the accumulator value is functionally dependent on a computation that fails with a dynamic error.</p></note> <note><p>Particularly in the case of streamed accumulators, this may mean that the implementation has to "hold back" the error until the next time the accumulator is referenced, to give applications the opportunity to catch the error using <elcode>xsl:try</elcode> and <elcode>xsl:catch</elcode> in a predictable way.</p></note>
Note one consequence of this rule: in test stream-203, a type error occurs putting a value in a map while applying xsl:accumulator-rule/@select, and the error is deferred until accumulator-before() is called. But this call occurs while evaluating the predicate of a match pattern, which masks the error; so it goes unreported, leading to difficulty in diagnostics. (However, Saxon gives a warning when an error occurs matching a pattern, so all is not lost.)
The WG approved the change, with two observations that have been applied: (a) there was no mention of the change in Appendix L (b) it's worth a note to mention that errors in xsl:accumulator-rule/@match are covered by the general rules on errors in patterns in section 5.5.4