How should business errors be handled in a web application?

Question

Say that I've got a web application that can store Persons in a database. Every Person must have a unique email address (or username or whatever). If a user attempts to add a Person with an email address that already exists, the form should be returned with an error message (like it would during a typical validation failure).

How is this kind error most typically bubbled up from the service layer to the controller and then to the view? Should the service method throw an exception for the controller to catch, or return a value or some kind of result object?

If I eventually want to use my service layer to generate a web service, does this change how I might proceed?

Any suggestions or links to best practices / sample applications would be appreciated.

Answer 1

One way to handle this is to create a response object for your addPerson operation that has a status code. For example:

class AddPersonResponse {
    private Person person;
    private AddPersonStatus status;
    private AddPersonFailureReason failureReason;
}

enum AddPersonStatus {
    SUCCESS, FAILURE
}

enum AddPersonFailureReason {
    DUPLICATE_EMAIL_ADDRESS,
    DUPLICATE_USER_NAME
}

The view you send the user to can bind to the response object returned by the service and give appropriate feedback.

Answer 2

I think I would choose to throw an exception. You could create a custom exception derived from the Exception class. This way, you are able to use the 'Message' field from your class as an end-user friendly message while still being able to log the actual exception details from the base's 'innerException' field. This way you can choose to hide the ugly details of why your method failed to the user while still maintaining the verbosity of the base's exception description.

Answer 3

This discussion is age-old and you will find different camps. My take on this is that if you have a backend system which has a clear standalone function, you should develop that first, with an API and everything, and then use that API from your view layer. In this case, layering is warranted. One example is that you are writing a web frontend to your already developed custom software.

In most webapps, however, it is much easier and more straight forward to use one single source of configuration. Django, RoR, JBoss Seam etc all take this approach. They use a concept centering around a set of domain classes, where all validation logic and constraints are put. Model exceptions (such as NoSuchObject) gets directly mapped to view exception (404 Not Found), all handled by the framework. With this approaches, there are no layers, and the main idea is to avoid layering until it is really needed. The Django docs are a real good source of information on this topics, and the Seam ones are more technical but also more detailed.

The decision to expose some logic as a web service does not automatically warrant a decision of building a complete layered solution, it is easy to refactor, YAGNI and DRY rule here I would say.

Layering really adds another dimension of problems propagating information back and forth, and I would say that unless it fits your problem well, don't use it.

Answer 4

I must say that I'm not a huge fan of the "validation errors are exceptions" pattern.

My model Save() methods simply create and return a list of broken rules (or an empty list.) It is then the job of my ControllerBase (or service layer) to handle those broken rules however they see fit.

In the case of my ControllerBase, I add them one by one to the MVC validation handler via AddModelError. In the service layer, it ends up being something like adding a "isValid" flag to my JSON result.

Answer 5

There are basically two ways of doing this: exceptions and returning the results of business rules validation. Each way has its advantages and disadvantages, but basically:

Exceptions:

• you can return only one failed result at the time
• exceptions are easy to implement and do not complicate your business logic - simply check the condition and throw a business exception
• exceptions work only for blocking rules
• open transactions can be easily rolled back

Business rules validation:

• you can check multiple business rules and return the list of broken ones to the user
• multiple rules can complicate the flow of your logic, because they tend to mess up the return types from methods
• they allow more scenarios to be handled, e.g. non-blocking informational rules

I think it heavily depends on the application which approach suits better, so there is no simple answer. For a long time I successfully used exceptions for business rules, now I tend to leverage the second approach.

Answer 6

The approach I use with Spring MVC is to perform all validation within the my Validator class. So from within my validate method I would call a method on the service to check if the email address was already used. If it was a duplicate I would add an error for that binding to the Errors object for showing on the form. If the Person object was valid you should then not need to worry about expections being thrown when it is added to the service.