<div><br></div><div> All,</div><div><br></div><div> I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching.</div><div><br></div><div>X( a.b.c == <value> )</div>
<div><br></div><div> 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. </div>
<div><br></div><div> Another example we had in the past:</div><div><br></div><div>class Circle implements Shape</div><div>class Square implements Shape</div><div><br></div><div>rule X</div><div>when</div><div> Circle() from $shapes</div>
<div>...</div><div><br></div><div> 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.</div>
<div><br></div><div> So, IMO, all property navigation should be null pointer safe in the LHS of the rules. </div><div><br></div><div> This is not what happens today, but I think it should be fixed.</div><div><br></div>
<div> Edson</div><div><br></div><div> </div> <br><br><div class="gmail_quote">2011/7/28 Vincent LEGENDRE <span dir="ltr"><<a href="mailto:vincent.legendre@eurodecision.com">vincent.legendre@eurodecision.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div style="font-family:Times New Roman;font-size:12pt;color:#000000">Hi all,<br><br>I agree with W. : NPE should be the default, and "null" cases behaviour should be planned by programmers.<br>
But I am not sure about using a new operator in rules (and do the update in Guvnor ...). <br>Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? <br>
And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ?<br><font color="#888888"><br>Vincent.<br></font></div></div><br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>