#577 NPE with invalid constant predicate

v8.8
closed
Michael Kay
5
2012-10-08
2006-09-06
Michael Kay
No

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.

Discussion

  • Logged In: YES
    user_id=1612213

    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 =
    context.getConfiguration().getTypeHierarchy();
    err = new DynamicError("Effective boolean value
    is not defined for an atomic value of type " + getItemType
    (th).toString(namePool));
    }
    err.setIsTypeError(true);
    err.setErrorCode("FORG0006");
    err.setXPathContext(context);
    throw err;
    // unless otherwise specified in a subclass
    }

     
  • Michael Kay
    Michael Kay
    2006-10-03

    Logged In: YES
    user_id=251681

    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.