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

[David Sinclair]

Doh! Thanks Greg, i didn't realize it was on dev.

Yes, there should be joins if there are multiple Facts. I am used to people
here just asserting one object and reasoning over it;  because you know,
rule engines aren't good at handling many facts ;)

On Tue, Feb 24, 2009 at 1:34 PM, Greg Barton <greg_barton at yahoo.com> wrote:

> David, please don't take this to be picking on you, but the rule you wrote
> wasn't quite correct. :)
>
> when
>       $f : Fact()
>       Detail(fact == $f, name == "END_SET", value == true)
>       Detail(fact == $f, name == "SET", value = 1)
>       Detail(fact == $f, name == "PLAYER1_SCORE", $score1 : value)
>       Detail(fact == $f, name == "PLAYER2_SCORE', value < $score1)
> then
> ...
> end
>
> Match the Details to their parent Fact.  I just want to make sure the newb
> doesn't get a combinatorial explosion and run screaming. :)
>
> And, not picking on both of you, but this should be on rules-users and not
> rules-dev.
>
> --- On Tue, 2/24/09, David Sinclair <dsinclair at chariotsolutions.com>
> wrote:
>
> > From: David Sinclair <dsinclair at chariotsolutions.com>
> > Subject: Re: [rules-dev] Dealing with null pointer exceptions thrown by
>  parsing rules
> > To: "Rules Dev List" <rules-dev at lists.jboss.org>
> > Date: Tuesday, February 24, 2009, 12:13 PM
> > Alex, please don't take this to be picking on you; this
> > is more a post to
> > everyone whom reads these forums.
> >
> > You are not writing procedural, object-oriented, or
> > functional code. You are
> > writing rules to look for patterns of objects. If
> > everything is done in an
> > eval you are losing the majority of the benefits of using a
> > rule engine, e.g
> > node sharing, indexing, etc. Flesh out your object model.
> > Assert all of your
> > objects into Working Memory. This will allow you to reason
> > over anything
> > without using evals.
> >
> > OK -- rant off --
> >
> > Alex, you may want to try and refactor your model to be
> > more "rules
> > friendly". That way your could write rules more like
> > the following.
> >
> > when
> >        $f : Fact()
> >        Detail(name == "END_SET", value == true)
> >        Detail(name == "SET", value = 1)
> >        Detail(name == "PLAYER1_SCORE", $score1 :
> > value)
> >        Detail(name == "PLAYER2_SCORE', value <
> > $score1)
> >
> > On Tue, Feb 24, 2009 at 12:39 PM, Zevenbergen, Alex <
> > azevenbergen at paddypower.com> wrote:
> >
> > >  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
> > >
> > >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090224/92a60103/attachment.html