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(a)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-tp320442...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users