All,
I think we need to differentiate paradigms
here. When using rules, contrary to imperative
code, what we are doing is pattern matching.
X( a.b.c == <value> )
In the above case, we are looking for Xs
that make that whole constraint true (i.e. match).
If a or b are null, the whole expression will be
false, does not matter the value of c or the value
it is being compared against. Raising a null
pointer exception, IMO, brings no advantage at all
to the table... on the contrary, makes writing
rules more difficult.
Another example we had in the past:
class Circle implements Shape
class Square implements Shape
rule X
when
Circle() from $shapes
...
In the above example, $shapes is a list and
the rule is clearly looking for Circles. If there
are Squares in there, they will just not match.
Raising a ClassCastException like it would happen
in an imperative language brings no advantage to
the table, IMO.
So, IMO, all property navigation should be
null pointer safe in the LHS of the rules.
This is not what happens today, but I think
it should be fixed.
Edson
2011/7/28
Vincent LEGENDRE
<vincent.legendre@eurodecision.com>
Hi all,
I agree with W. : NPE should be the default,
and "null" cases behaviour should be planned
by programmers.
But I am not sure about using a new operator
in rules (and do the update in Guvnor ...).
Why not using some drools annotations on the
getter specifying the behaviour of an eval
on a null value returned by this getter ?
And may be these annotation could be added
to an existing POJO via the declared type
syntax (just like event role in fusion) ?
Vincent.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com