Error Handling without Exceptions
I think you've gotten the wrong impression of the intended message. Here's a great quote I ran across yesterday from the current edition of Visual Studio magazine (Vol 19, No 8).
Either a member fulfills its contract or it throws an excetion. Period. No middle ground. No return codes, no sometimes it works, sometimes it doesn't.
Exceptions should be used with care as they are expensive to create and throw--but they are, however, the .NET framework's way of notifying a client (by that I mean any calling component) of an error.
I assume that you are creating your own business rules validation engine, since you haven't mentioned the one you're using.
I would use exceptions, but I would not throw them. You will obviously need to be accumulating the state of the evaluation somewhere - to record the fact that a particular rule failed, I would store an Exception instance describing the failure. This is because:
- Exceptions are serializable
- Exceptions always have a
Messageproperty that is human-readable, and can have additional properties to record details of the exception in machine-readable form. - Some of the business rules failures may in fact have been signaled by exceptions - a
FormatException, for instance. You could catch that exception and add it to the list.
In fact, this month's MSDN Magazine has an article that mentions the new AggregateException class in .NET 4.0, which is meant to be a collection of exceptions that occurred in a particular context.
Since you're using Windows Forms, you should use the built-in mechanisms for validation: the Validating event and the ErrorProvider component.