[rules-dev] Dealing with null pointer exceptions thrown by parsing rules

[Edson Tirelli]

   When you fall back into pure java (i.e., inside eval) there is nothing
drools can do.
   Did you tried writing the rule in a drools pattern itself, instead of
java eval?

when
   $f : Fact( details.END_SET == true, details["set"] == 1,
details['PLAYER1_SCORE'] > details.PLAYER2_SCORE )
then
   // do something
end

   In the example above I mixed several ways you have to access Map
elements, just to show it is possible. I prefer the "." notation, but up to
you.

   I didn't tested this, though... you need to check if that will raise NPE
(I think it won't, but not sure) and also the use of the map element on the
right side of the expression (details.PLAYER2_SCORE).

   []s
   Edson

2009/2/24 Zevenbergen, Alex <azevenbergen at paddypower.com>

>  Thanks for replying.
>
>
>
> rule "Player 1 wins first set "
>
>     when
>
>       $f : Fact()
>
> eval ($f.getDetails().get("END_SET").toString() == "true" && Integer.valueOf($f.getDetails().get("SET").toString())
> == 1 && Integer.valueOf($f.getDetails().get("PLAYER1_SCORE").toString()) >
> Integer.valueOf($f.getDetails().get("PLAYER2_SCORE").toString()))
>
>     then
>
>       //then settle selection;
>
> end
>
>
>
>
>
> this rules runs perfectly as long as the hashmap contained in the ‘fact’
> object has all the required keys and their values are not null. For the time
> being I have just changed any null values to a value of ‘DEFAULT’ but it
> would be preferable to be able to look for f.getDetails().get("END_SET") (for
> example) knowing that the engine that sent it might not be in an end_set
> state so may not have added that key.
>
>
>
> That example is very basic but as I create more rules for more sports it
> could become very cumbersome to have to ensure that every key referenced in
> the rules is in the hashmap each time!
>
>
>
> Alex
>  ------------------------------
>
> *From:* rules-dev-bounces at lists.jboss.org [mailto:
> rules-dev-bounces at lists.jboss.org] *On Behalf Of *David Sinclair
> *Sent:* 24 February 2009 17:27
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Dealing with null pointer exceptions thrown by
> parsing rules
>
>
>
> I understand what you are saying Alex, but could you post an example rule
> to see exactly how you are doing it? It may be that you could simply rewrite
> the rule so you don't get the NPE.
>
> On Tue, Feb 24, 2009 at 4:24 AM, Zevenbergen, Alex <
> azevenbergen at paddypower.com> wrote:
>
> Hi all,
>
>
>
> I have started writing my rules packages and so have had a decent amount of
> success. However all my rules are based on value pairs from a hashmap object
> that is contained within my fact object. This approach works fine if the
> parameter the rule is looking for is in the map and has a value.
>
>
>
> But I will need to be able to pass null values to the rules (and expect
> them to just not fire any rule that looks for that param), however this
> always throws a null pointer exception.
>
>
>
> So my question is: Is there any mechanism to deal with this in drools.
>
>
>
> Simply setting all nulls to a default value isn’t preferable in this
> situation as the app is going to be used by several different sources and
> has to be able to take in many different types of info.
>
>
>
> Thanking you,
>
>
>
> Alex
>
>
> ________________________________________________________________________
> Privileged, confidential and/or copyright information may be contained in
> this communication. This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you are not the intended addressee, you may not
> copy, forward, disclose or otherwise use this e-mail or any part of it in
> any way whatsoever. To do so is prohibited and may be unlawful. If you have
> received this email in error
> please notify the sender immediately.
>
> Paddy Power PLC may monitor the content of e-mail sent and received for the
> purpose of ensuring compliance with its policies and procedures.
>
> Paddy Power plc, Airton House, Airton Road, Tallaght, Dublin 24 Registered
> in Ireland: 16956
> ________________________________________________________________________
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> ________________________________________________________________________
> Privileged, confidential and/or copyright information may be contained in
> this communication. This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you are not the intended addressee, you may not
> copy, forward, disclose or otherwise use this e-mail or any part of it in
> any way whatsoever. To do so is prohibited and may be unlawful. If you have
> received this email in error
> please notify the sender immediately.
>
> Paddy Power PLC may monitor the content of e-mail sent and received for the
> purpose of ensuring compliance with its policies and procedures.
>
> Paddy Power plc, Airton House, Airton Road, Tallaght, Dublin 24 Registered
> in Ireland: 16956
> ________________________________________________________________________
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20090224/dfe43a5a/attachment.html