preconditions and exceptions

Question

Suppose you have a method with some pre and post-conditions. Is it ok to create an exception class for each pre-condition that is not accomplished? For example: Not accomplishing pre1 means throwing a notPre1Exception instance.

Answer 1

Only if not accomplishing the pre-conditions would be a rare exceptional occurrence.

Answer 2

Sounds like a useful use of exceptions to me. It certainly allows more fine-grained logging and debugging than just a general 'precondition failed' although you could also have a single 'preconditions failed' exception and put what preconditions have failed into the exception message.

Answer 3

Why wouldn't you want to define PreconditionFailedException(string precondition)? Throwing a different exception type for each failed precondition is overkill.

Answer 4

I think it's ok to create a different exception for all your exceptions as long as you plan on using and handling them.

I have found that the better the error/exception handling the easier it is to debug software in the later stages.

For example: If you have a generic excpeiton to handle all bad input then you must look at everything that was passed into the method if there is an error. If you have an excpetion of all the types of bad conditions you will know exaclty where to look.

Answer 5

It looks possible to me, but if you want to continue this way of dealing with preconditions, you'll end up with N exception classes per class method. Looks like an explosive growth of 'non functional' classes.

I always liked code where the 'core' functionality didn't handle violation of preconditions (apart from asserting them - a great help!). This code can then be wrapped in a 'precondition-checker', which does throw exceptions or notifies non-satisfaction otherwise.

Answer 6

As a very very general way to determine if you should ever create a class or not (and an exception is a class), you should determine if there is some code that makes this class unique from all other classes (in this case exceptions).

If not, I'd just set the string in the exception and call it a day. If you are executing code in your exception (perhaps a generic recovery mechanism that can handle multiple situations by calling exception.resolve() or something), then it might be useful.

I realize that exceptions don't always follow this rule, but I think that's more or less because exceptions provided by the language can't have any business logic in them (because they don't know the business--libraries always tend to be full of exceptions to the OO rules)

Answer 7

A failed precondition should throw an AssertException, or something similar. Before invoking a method, it's precondition must hold. If the caller doesn't do this check, it's a bug in the program, or an incorrect use of the method (API).

Answer 8

I would say it's okay as long as you make them unchecked exceptions (subclass of RuntimeException in Java). However, in Java it is better to just use assertions.

Answer 9

Yes and no.

Yes - Violating a precondition is certainly an appropriate time to throw an exception. Throwing a more specific exception will make catching that specific exception simpler.

No - Declaring a new exception class for every precondition in your program/api seems way overkill. This could result in hundreds or thousands of exceptions eventually. This seems a waste both mentally and computationally.

I would recommend throwing exceptions for precondition violations. I would not, however, recommend defining a new exception for each precondition. Instead, I would recommend creating broader classes of exceptions that cover a specific type of precondition violation, rather than a specific precondition violation. (I would also recommend using existing exceptions where they fit well.)

Answer 10

I think Ben is on target here. What's the point in throwing different exceptions if you're not going to catch them? If you really want to throw a different one I would at least have a common "PreconditionFailedException" base class that they all derive from, and try to organize them into some sort of heirachy so you can catch groups of them. Personlly, I'd not have different ones and just have a common exception you throw with the details of the failure in each one.

Answer 11

If you do this, make sure they all inherit from another common custom exception.

Answer 12

No, you should not create a specific exception for each precondition because it will go against the principles of the Design-by-Contract.

The corollaries of implementing pre-conditions is that they should be part of the documentation and that you should provide the necessary methods for the caller to check that all the preconditions are valid. (i.e. if a method execution is relying on the status of an object, the method to check the status should be available to the caller).

So, the caller should be able to check if all prerequisites are met before calling your method.

Implementing specific exceptions for each violated pre-condition would/could encourage the caller to use the try/catch pattern around the method call, what is in contradiction with the philosophy of the Design-by-Contract.