Two points to consider:

(1) If a programmer writes
a.getB().getC() == <something>
and a NPE happens due to a.getB() == null we may distinguish (a) and (b) - see below.

(a) The setup is so that this is to be expected but the programmer forgot to take this possibility into account. Then we have:

(a1) The consequence of a.getB() == null should be the same as a.getB().getC() == null.

(a2) If a.getB() == null, something else needs to be done, e.g., a.setB(x). If this is silently covered by the system, the absence of handling will not be detected so easily.

(b) The assumption is that a.getB() should never be == null in the first place, but some other error (in data or code) caused this. If this is silently covered by the system, this error will not be detected so easily.

(2) If a.getB().getC() == <something> returns false if a.getB() is null, is this also the desired result if <something> is "null", i.e., do you want
a.getB().getC() == null
to be false if a.getB() == null ?

"Null safe navigation" is a nice try and *may* be tolerable, but it should never be the default.

-W

On 28 July 2011 14:06, bolsover <david@bolsover.com> wrote:

Thanks for the pointer to the MVEL documents - I can forsee null-safe
operator user.?manager.name syntax being most useful.

As for making the null test the default action - I'm not sure - I can't say
I have ever actually 'wanted' a nullpointer - but there may be some special
case.

David

--
View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3206467.html

Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users