Good point. We will have to mention it in the manual for Drools 3. As a general rule, I would say don't throw any exceptions unless you want to rudely interrupt execution - that pretty much applies to any framework. In my naive youth, I use to use exceptions as means of communicating UI validation failures for instance, but they are not designed for that (you can all point and laugh at me now), and it killed performance.
It would be possible for us to trap exceptions that occur in rule code, but I don't think that would be expected - once an exception occurs, it is reasonable to expect the rule engine to cease operation as a rule engine, and return control to the caller as soon as possible (other people can correct me if they have other ideas). On 1/31/06, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote: > > On 1/30/06, Michael Neale <[EMAIL PROTECTED]> wrote: > > > > yep validation like that definately should be done with an object and a > > collection. > > > > Like you say, have a ValidationList class, and .addValidationFail() > method > > that accumulates it. Exceptions generally are best avoided unless there > is > > something seriously wrong. This is analagous to web frameworks where > they > > have .addError() methods (like in struts for an unpleasant example). > > > Wouldn't hurt to have some documentation covering Drools and exceptions so > that people understand more clearly what happens when a rule throws an > exception, when that would be a good idea and when it wouldn't. > > > -- > Geoffrey Wiseman > >
