While searching SO for approaches to error handling related to business rule validation , all I encounter are examples of structured exception handling.
MSDN and many other reputable development resources are very clear that exceptions are not to be used to handle routine error cases. They are only to be used for exceptional circumstances and unexpected errors that may occur from improper use by the programmer (but not the user.) In many cases, user errors such as fields that are left blank are common, and things which our program should expect, and therefore are not exceptional and not candidates for use of exceptions.
QUOTE:
Remember that the use of the term
exception in programming has to do
with the thinking that an exception
should represent an exceptional
condition. Exceptional conditions, by
their very nature, do not normally
occur; so your code should not throw
exceptions as part of its everyday
operations.
Do not throw exceptions to signal
commonly occurring events. Consider
using alternate methods to communicate
to a caller the occurrence of those
events and leave the exception
throwing for when something truly out
of the ordinary happens.
For example, proper use:
private void DoSomething(string requiredParameter)
{
if (requiredParameter == null) throw new ArgumentExpcetion("requiredParameter cannot be null");
// Remainder of method body...
}
Improper use:
// Renames item to a name supplied by the user. Name must begin with an "F".
public void RenameItem(string newName)
{
// Items must have names that begin with "F"
if (!newName.StartsWith("F")) throw new RenameException("New name must begin with /"F/"");
// Remainder of method body...
}
In the above case, according to best practices, it would have been better to pass the error up to the UI without involving/requiring .NET's exception handling mechanisms.
Using the same example above, suppose one were to need to enforce a set of naming rules against items. What approach would be best?
Having the method return a
enumerated result?
RenameResult.Success,
RenameResult.TooShort,
RenameResult.TooLong,
RenameResult.InvalidCharacters, etc.
Using an event in a controller class
to report to the UI class? The UI calls the
controller's RenameItem method, and then handles an
AfterRename event that the controller raises and
that has rename status as part of the event args?
The controlling class directly references
and calls a method from the UI class that
handles the error, e.g. ReportError(string text).
Something else... ?
Essentially, I want to know how to perform complex validation in classes that may not be the Form class itself, and pass the errors back to the Form class for display -- but I do not want to involve exception handling where it should not be used (even though it seems much easier!)
Based on responses to the question, I feel that I'll have to state the problem in terms that are more concrete:
UI = User Interface, BLL = Business Logic Layer (in this case, just a different class)
User enters value within UI.
UI reports value to BLL.
BLL performs routine validation of the value.
BLL discovers rule violation.
BLL returns rule violation to UI.
UI recieves return from BLL and reports error to user.
Since it is routine for a user to enter invalid values, exceptions should not be used. What is the right way to do this without exceptions?
