Should a business rule violation throw an exception?

Question

Should a business rule violation throw an exception?

Answer 1

There is good guidance in the wiki for the book 97 Things Every Project Manager Should Know, in particular in the chapter Distinguish Business Exceptions from Technical.

So, if your programming language supports it, the best thing is to create custom exception classes so the their workflow and handling can be different from technical exceptions.

Answer 2

No Violating a business rule is a BUSINESS issue where an exception is a technical one. Violating a business rule is something that the system should regard as normal operation and for which it should have a programmed response, not an exception.

Answer 3

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 4

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

Answer 5

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 6

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.