38th: Check the validity of the parameters

The vast majority of methods and constructors have some limitations on the parameter values passed to them. For example, index values must be non-negative, object references cannot be null, and so on.

All of these limits should be clearly indicated in the document, and check parameters at the beginning of the method body to enforce these restrictions. This is "an error should be detected as soon as possible after the error has occurred"

A specific case of this universal principle.

If you pass an invalid parameter value to the method, the method checks the parameter before executing it, and it will soon fail and clearly throw the appropriate exception. If it is not checked

Parameters can occur in several cases. The method may fail during processing and produce a confusing exception. Worse, the method can return normally, but the result returned

may be the result of a mistake. The worst case scenario is that the method can return normally, but it causes an object to be in a corrupted state, and in the future, at some indeterminate time, in some

An error is raised on the associated point.

For public methods, the exception that is thrown when a violation of a parameter value restriction is indicated in the document with the Javadoc @throws tag. Usually such an exception is IllegalArgumentException,

Indexoutofboundsexception.

For a method that is not exported, that is, the method is not called by the client code, as the creator of the package, you can control under what circumstances this method will be invoked, so you can ensure that

Only valid parameter values are passed in. Therefore, non-public methods should use assertions (assertion) to examine the parameters.

The assertion assumes that the expression following the Assert keyword is true, and if the actual parameter value passed in is not the same as our hypothesis, it will automatically throw the assertionerror without the need to display the manual throw.

But not every method we need to check the validity of the parameters, for example, in some cases, the effectiveness of the inspection work is very expensive, or is simply impractical, and the effectiveness of the check

has been implicitly completed during the calculation.

In short, whenever you write a method or constructor, you should consider the limitations of its parameters. These limits should be written in the comment document above the method, and the validity of the implementation should be considered

Check the cost, weigh the pros and cons, and finally show the checks to implement these validity. It is very important to develop such a habit.

38th: Check the validity of the parameters