Usage of Exceptions

Question

In a Spring application, my point of view is that each domain model which in fact is a POJO, should encapsulate all the validation logic in itself. Now whenever there is an update or insertion, they should throw proper exceptions that are modeled after the business process like CustomerNotFound AlreadySold, CannotAllowReturnOfExpiredItem and like.

These exceptions are not caught at the DAO or Service layer rather in controllers and each exception has a message key that is displayed on the view after getting it through the Application.Resources.

My question is that Exceptions being used in this way, is this appropriate? Some are of the view that exceptions are only for the debugging purposes and they'd let you know what's wrong and where so throwing exceptions from the business logic is not a good thing.

What would you add to this?

Answer 1

In most cases it is not necessary to throw an exception. For example, for CustomerNotFound it is a matter of returning an empty list; for AlreadySold or CannotALlowReturnOfExpiredItem you return the number of items affected, zero meaning the operation was not possible. This way the DAO is ignorant to rules and it is up to the business layer to decide if that condition is an error or not.

Answer 2

Here's something to consider: Suppose a method 'getCustomerById()' from your class 'CustomerService' returns 'Customer' objects based on a 'customerId'. On success, it returns 'Customer' objects.

On failure, would you rather have it return a dumb 'null'? Or would you want to get a very descriptive 'CustomerNotFoundException'?

A general rule can be: when your method returns error codes that are not of the same type as its success return values, Exception should be used.

jrh.

Answer 3

I would suggest thinking of the Exception you wish to throw in the context of the layer in which you are developing. In your example, a CustomerNotFoundException would not make sense being generated by the customer itself. A DAO/Service may be a more appropriate place for this error, which could be caught by the controller and could then be translated into an error message for the user.

In my experience, there are different contexts to validation, and must therefor be handled at multiple levels. An example of this would be a customer; at the customer object level, you need to verify that the customer's date of birth is a valid date, while the business rule that if this customer is purchasing product Y, the customer must be over 18 (using the already valid date in the customer). The customer should not have any knowledge of products, or age restraints, but the OrderService for example, would.

I recommend that you preform basic logic validation on the bean itself, but push all other validation into a service/manager layer.

Answer 4

I tend agree with ocdecio and Rich Kroll but would like to add something I think may of been missed.

Deciding whether to return null or throw an exception all depends on your architecture. If you display errors to the screen that are captured by exceptions then I would throw an exception. If you don't then maybe returning null is better.

(If the use case is to find more than 1 result, then an empty list should be used but I don't think this is what you meant).

In many cases I have seen null returned and then in the caller manually raises an exception. It seems to me that both use-cases should be implemented in a service and the developer can decided which is the most appropriate api call to make.