[rules-users] Are there second-rate fact types?

[Davide Sottara]

In fact what we have now is *NOT* graceful
I'll open a JIRA and try to provide a fix


On 06/10/2014 01:52 PM, Wolfgang Laun wrote:
> On 10/06/2014, Davide Sottara <dsotty at gmail.com> wrote:
>> java.util.Collections (and descendants) are not @typesafe by default,
>> I'll check the reason for that.
> OK.
>
>> More generally, if a fact is declared as not @typesafe, the runtime
>> failure should be more graceful.
> But (according to you)  java.util.Collections is *not* @typesafe, and
> this runtime failure cannot be called "graceful".
>
> Can a java.util.X be declared as @typesafe? If so, how? Is any of this
> documented anywhere?
>
> -W
>
>> Davide
>>
>> On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
>>> Consider:
>>>
>>>    class Foo { /*...*/ }
>>>
>>>    rule checkFoo
>>>    when
>>>       Foo( noSuchField > 0 )
>>>    then ... end
>>>
>>> DRL compilation reports an error (Error: unable to resolve method ...)
>>> and identifies rule, line and column, which is fine.
>>>
>>> Now let's look at:
>>>
>>>    import java.util.ArrayList;
>>>    rule checkArrayList
>>>    when
>>>       ArrayList( noSuchField > 0 )
>>>    then ... end
>>>
>>> The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
>>> there is a nasty exception thrown at runtime. This is inconvenient,
>>> since the exception can be thrown by any code inserting an ArrayList
>>> object, and the faulty rule isn't identified.
>>>
>>> Why are certain classes second-rate?
>>>
>>> -W
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> .
>