#577 NPE with invalid constant predicate

Michael Kay
Michael Kay

If a query contains a filter expression whose predicate
is a compile-time constant, and has an incorrect type
(a type such as xs:hexBinary for which no effective
boolean value is defined) then a NullPointerException
is thrown at compile-time instead of reporting a proper
error message.

This is shown by XQTS test case K-FilterExpr-91.
(Saxon's test driver failed to distinguish the NPE from
a normal compile-time error, merely reporting that the
wrong error code was signaled).

The code (in net.sf.saxon.expr.FilterExpression) will
be patched in Subversion.


  • Logged In: YES

    Hi. I did solve this problem shielding effectiveBooleanValue
    (XPathContext context) at AtomicValue from a NPE, but the
    solution you got is much better.

    But, even that problem had just been solved, don't you
    think that will be a good thing to shield the method only
    for sake ?

    That is how its look like :

    public boolean effectiveBooleanValue(XPathContext

    context) throws XPathException {
    DynamicError err = null;
    if(context==null) {
    err = new DynamicError("Effective boolean value
    is not defined for an atomic value of type other than
    boolean, number, string, or URI");
    } else {
    final NamePool namePool = context.getNamePool();
    final TypeHierarchy th =
    err = new DynamicError("Effective boolean value
    is not defined for an atomic value of type " + getItemType
    throw err;
    // unless otherwise specified in a subclass

  • Michael Kay
    Michael Kay

    Logged In: YES

    No, that patch would be quite incorrect. It would be wrong
    for AtomicValue.effectiveBooleanValue() to assume that it's
    being called to evaluate a filter in a filter expression,
    and it would be wrong to assign a special meaning to
    supplying a null value for the context argument.

    In the past there was a convention that when evaluating
    constant subexpressions, it was OK to supply a null context,
    because the result can never be context-dependent. However,
    there are some awkward cases where results are indeed
    context dependent, for example they can depend on implicit
    timezone or on the choice of XML 1.0 versus XML 1.1
    character sets in types such as xs:NCName. So the code was
    changed to always supply a context object, even when
    evaluating expressions at compile time, and even when
    evaluating "values". The NPE happened because this change
    hadn't been applied on this path, and the correct fix is to
    apply it.