Agreed. It was poor design on my part as I realised that I couldn't do all the validation in one hit and return all the errors for that logical unit of work. Remedied that one now, reserved the exceptions for something critical/fatal.
On 1/31/06, Michael Neale <[EMAIL PROTECTED]> wrote: > 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 > > > > > >
