<br> Well, we can't let the the exception escape the consequence block, since it would invalidate the working memory. <br> So, we have 2 options I think:<br><br>* If we make the validation framework enforce valid values, we need it to raise an exception that is catch by a transparent consequence catch block and is handled the same way we already handle them, but stopping rule firing.
<br><br>* If we make the validation framework just warn about invalid values, we can create a warning mechanism so that users can handle such warnings, but let the value to be set and continue running the engine as if no problem was found.
<br><br> I don't see many other options on that... I still prefer first option.<br><br> My 0.02c.<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2008/1/8, Mark Proctor <<a href="mailto:mproctor@codehaus.org">
mproctor@codehaus.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Michael Neale wrote:<br>> I don't like the catch block idea at all. We have a rule language not
<br>> a programming language.<br>How do we deal with invalid sets? Without a catch block, ther "then"<br>scoped or "modify" scoped, we have only two choices - always throw an<br>exception, do nothing and just expose a validator variable. Considering
<br>we don't want to add 'if' statements into the consequence how would the<br>user then handle processing the validator variable?<br>><br>><br>> Sent from my iPhone<br>><br>> On 08/01/2008, at 6:49, Mark Proctor <
<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>> wrote:<br>><br>>> I'm thinking about an ontology constraint system, based around field<br>>> setter validation. However I cannot decide how to handle invalid
<br>>> changes in a consequence or in external java code. I'll may leverage<br>>> the JSR 303 - Bean Validation - <a href="http://jcp.org/en/jsr/detail?id=303">http://jcp.org/en/jsr/detail?id=303</a>.<br>>>
<br>>> Although I have several concerns with the spec, one is that it always<br>>> validates objects and passes in the field as an object - with<br>>> primitive intensive stuff that can add an overhead, due to auto
<br>>> boxing. I'm more tempted to pass in the main Object itself and users<br>>> can then use the FieldExtractor to read the field as they require,<br>>> either as an Object or a primitive with full co-ercion - the
<br>>> FieldExtractor would be injected. Further to that I can't see how you<br>>> would make the validator session aware, and doing it via constructor<br>>> injection would mean a validator per session which is not desirable.
<br>>> I spoke to the spec lead and he mentioned using LocalThread<br>>> variables. However we can have multiple sessions in the same thread,<br>>> just not executing at the same time, which means the current
<br>>> executing session would need to set itself on that localthread<br>>> variable - basically context switching, which I don't like.<br>>><br>>> We should have a variable that lists the validator errors for the
<br>>> current working memory action phase, for user interrogation - much<br>>> like Hibernate Validator (RI for JSR 303) allows you to list<br>>> validation errors on a insert or update on a session.<br>
>><br>>> But in rule engines we have other considerations:<br>>> The first fundamental question is do we allow invalid changes or do<br>>> we always roll them back? My prefernce, much like a database, is the
<br>>> data model as seen by the engine is always valid.<br>>><br>>> Now if we assume the invalid change must be rolled bank or not<br>>> applied how do we expose this to the user:<br>>> -Throw an exception, up to them if they catch and it will exit the
<br>>> engine if not caught.<br>>> -Do nothing, roll back the change and continue executing the<br>>> consequence as normal, they can check the validator variable if they<br>>> need to.<br>>> Allow for "catch" like blocks either after each modify block, or
<br>>> after the "then" block. Do we have one large catch block, or do we<br>>> have some sort of type matching....<br>>><br>>> Currently my preference is for a "catch" block after the "then"
<br>>> block. I'm tempted to just have one large catch block and users can<br>>> do an iteration of the validator variable doing "if" checks; we can<br>>> always add in type matching later. The catch block can either resume
<br>>> or throw an exception; on resumption it will attempt to validate the<br>>> bean again, if it's changed, if it's still invalid the process repeats.<br>>><br>>> Mark<br>>> _______________________________________________
<br>>> rules-dev mailing list<br>>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev
</a><br>> _______________________________________________<br>> rules-dev mailing list<br>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br><br>_______________________________________________<br>rules-dev mailing list<br><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br>
Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>