Should a business rule violation throw an exceptio

Question

Should a business rule violation throw an exception?

Answer 1

No. It's part of normal conditional-handling logic in the program (and often just a disguised form of user error).

Answer 2

It really depends on what it is and where it is.

If it's some data coming from the user then as levand said it's a matter of validation. Validation can turn up both successful and failed, both are expected options with clear further action scenarios.

If it's something like method execution errors it could be a better idea to throw an exception and stop right there before more harm is done (such as producing inconsistencies in the database).

It is often a matter of perspective and your application design.

Answer 3

I would say not normally but I don't think you can say never.

For instance it depends on who/what is handling of the failed rule. If it is a user interface/user then I would use conditional logic to deal with the failure appropriately. However if it is a business rule failure in, for instance, a faceless process that logs any errors to an event log which will be monitored by for a technical resource then an exception may be just as appropriate. In this later case an appropriately named exception can be just as helpful as a nicely formatted message.

Answer 4

First, a couple of quotes from chapter 18 of Applied Microsoft .NET Framework Programming (page 402) by Jeffrey Richter:

"Another common misconception is that an 'exception' identifies an 'error'."

"An exception is the violation of a programmatic interface's implicit assumptions."

If I'm inferring correctly from your question that a business rule violation would be data that falls outside a certain range (for example), this is an error that you could handle with a conditional as @ahockley suggested. Based on the definition of an exception from Richter, the appropriate use of an exception would be if your code wasn't able to retrieve a business rule from whatever repository you're using. Being able to retrieve a business rule would be a reasonable implicit assumption for that interface to have, so an exception should be thrown if this assumption was violated.

One good example of Richter's first quote (exception != error) is the ThreadAbortException. If you call Response.Redirect(url) (in ASP.NET), a ThreadAbortException is thrown even though the redirect succeeds. Why? The implicit assumption of ASP.NET page execution is that a page will execute completely. Response.Redirect(url) violates this assumption, hence the exception.

Answer 5

Throwing exceptions can be computationally intensive, they are outside of the norm. For example in .net you have performance counters that are incremented - that is a heavyweight acitivty and so not something you would want to do instead of a simple conditional.

Answer 6

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.