Most of methods and constructors have constraints on their parameters, but whether carry out a validity check differs from people to people. Recalling my own programming experience, I did rush to implement the business without making a check. But rigid habit shall be kept here, the little effort really brings back a lot.

If an invalid parameter is passed into a method with checking, a prompt and clear exception will be thrown, the situation can be quite different without a check. The method may fail somewhere on the way, reporting a confusing exception or error; to be worse, the method executed successfully, but giving back a wrong result, and the worst one, the method end with a correct result, but corrupted some relevant objects during the process, and these latent problems will break out somewhere or sometime you never know.

Therefore, the benefits of checking for validity actually comes from the fact that possibly lots of problems will appear without the checking. The door was too open and brings too much threat to future situation.

Besides checking parameters for calculation, more attention shall be put on the checking on parameters that are stored for later use. Without the checking, errors will occur sometime when the original instances are difficult to trace, which brings miserable experience to the debugging process. I supposed quite a lot of coders had tasted that. Constructors are a representative case, most of the parameters of constructors are for later uses, invalid parameters will violate invariants of the class, the exception it caused can be very weird and hard to solve.

There is exception. In some case which validity checking is expensive or impractical and the check can be perform implicitly in the process of calculation. For instance, a method sorting a list, for such a method, the objects in the list must be mutually comparable, otherwise a ClassCastException will be thrown, and it is exactly the exception a sorting methods should throws, so it will be meaningless to check them ahead of time. However, indiscriminate application of such techniques can lead to the loss of failure atomicity. For example, the method does more than sorting, it also do some writing operation of the objects, in such case, by the time an exception is thrown, some of the objects have already been modified, you have to roll back, or, accept a half complete result. This is discussed in detail in item 46. What’s more, sometimes exception thrown by implicit check can not tell the really problems, and you have to do some “exception translating” for revealing the real cause.

The above information does not means that arbitrary restrictions on parameters are a good thing. In fact, you shall put fewer restrictions on them as long as the method is capable of dealing the parameters. By this way we get more general methods.

To summarize, you shall consider what restrictions should exist on the parameters when you are writing a method or constructor, and document for them, apply explicit check in the beginning of the method body, it is important to get into the habit of doing this, this modest work will start pay back at the first time a validity check fails.