Should a business rule violation throw an exception?

Question

Should a business rule violation throw an exception?

Answer 1

Because of the way I do my validation and my use of LINQtoSQL for ORM, yes. If an entity fails validation on a business rule during the OnValidate method, the only way to notify the calling code is to throw an Exception. In this case, I throw a custom DataValidationException. Using the OnValidate method hook in a partial class implementation of the entity makes it possible for me to enforce validation on update/insert so only valid data gets saved to the database.

EDIT I should make it clear that I typically do validation of user input at the client so the persistence layer validation is typically more insurance and rarely, if ever, fails. I don't handle the client-side validation as exceptions, but rather with conditional logic.

Answer 2

Business rules should not throw an exception, unless they are used to validate parameters of some API (i.e.: checking requests validity) or in unit tests (i.e.: using business rules to simplify .NET unit tests).

Generally business rules output error and warning messages to the validation scope, though.

Answer 3

Usualy I put the condition in a Specification object that implements

bool IsVerfiedBy(T entity);

So you can check the condition without exception.

If there is a place in your code where the specification should be verified beforehand, you can throw an exception because this is a prerequisit of you function.

For instance if your entity must be in a specific state before persistance, throw an exception when the specification is not verified, but use the specification before persisting so that the exception does not happen.

Answer 4

It depends on what the business rule is, IMO. I would venture to say "not usually" but I'd view it on a case-by-case basis. I don't think there is any one answer, as different business rules might warrant it while others might not.

Answer 5

Business rules could throw exception but they shouldn't.

If you have another way to communicate information about common and predictable validation error, you should use it.

Answer 6

As an alternative view to most of the answers...

It can be useful to throw exceptions from the business logic, particularly if they are cuased by a failure in validation. If you are expecting an object and you get a null, it suggests that some problem has evaded detection in the user interface (or other interface). It may be completely valid to throw exceptions at this point. Indeed, you may decide to place this type of validation in the business logic when there are multiple interfaces.

Throwing exceptions in some languages / frameworks (I am thinking .NET) can be costly but this should not immediately worry you. It does mean that, at the name suggests, they are used for exceptional circumstances and not as part of the standard flow of a program. You certainly shouldn't throw an exception just to exit a method. You should also consider a graceful recovery where possible that may not include throwing an exception.

So, summing up... It depends...