Hi Pablo,
You are right; your expression raised an error, because the existence of documents is checked at compile-time (to allow for subsequent index rewritings, non-existing element names, etc.).
I realized that the behavior you observed was compliant with the spec, which does actually not dictate an evaluation order [1]. However, as we are already replacing compile-time errors with an fn:error() function in other expressions – such as if/then/else – and further operands are skipped once the final result is known, it was just consistent to do the same with and/or.
I have revised the code and uploaded a new snapshot [2]. Thanks for your report, Christian
[1] http://www.w3.org/TR/xquery-31/#id-logical-expressions [2] http://files.basex.org/releases/latest/
On Wed, Aug 5, 2015 at 7:59 PM, Strasser Pablo strasserpablo@bluewin.ch wrote:
Hi Christian,
Thanks for the answer.
It seem that if there is a call to the doc function it doesn't short-circuit.
Your exemple work, however this one does not: 1 or doc('non_existent')
Which return [FODC0002] Resource '/home/pablo/nonex' does not exist.
With respect of your answer I believe this behaviour is a bug.
Pablo
On 05/08/15 18:05, Christian Grün wrote:
Hi Pablo,
Should code of this type depending on the short-circuit evaluation of the and operator evaluate correctly?
Yes, it does. Here is a mini example (it would raise an error otherwise):
1 or error()
Hope this helps, Christian