Why you should check method parameters for validity

I was reading one tip from Effective Java today, item 23 check method parameters for validity. It was talking about why you should check method parameters for validity. This is often something which you can forget about because you are usually using the class and method yourself and when testing the code you pass in a correct value. Perhaps if you are unit testing you pass in some unusual values, given some confidence that you method has passed the other expected value tests.

This is a classic Effective Java tip, very simple but yet very .... yes I can't resist it Effective.

Implementing this tip and checking methods parameters for validity would help to eradicate one of the classic programmer/developer blind spots and probably the main reason for QA teams. Before you get angry with my preaching, I too have been guilty of this. When developers test their own code they often get into a kind of groove and only pass in a few different valued variables. They usually test something some many times they keep putting in the same value over and over until the code finally passes this test.

If we were writing a (as it's a boiling heat wave in Birmingham) method which converts Fahrenheit to degrees then the developer would pass in a few number 21, 10, 90 and usually write some code with just one of those value say 50 and keep testing the code with this until it works. After that a few different positive numbers, bingo the method is tested, give it the rubber stamp. The example I am using is without unit test code which was the way I used to work (before I had an epiphany and saw the light ).

Without checking for validity you are underestimating the sheer stupidness of the users. There is obviously the argument that you make your code idiot proof they will go and create an even greater idiot but we will leave that. Users love doing stupid things, sometimes to see if they can break it !!!!! It would be long before a user/customer would put in a negative number or perhaps even 1 million (dollars MWHAHHAA - doctor evil laugh) and then they would complain it wasn't working.

Of course the real nightmare scenario is that you would put in a dodgy/invalid value but this would only show up as an error ten classes down the road, leaving you with a puzzling bug hunt and some slow debugging back up to the method that has caused the error.

By checking the methods parameters for validity you can throw up an error as soon as possible so as to stop any more code running when you know it wouldn't work with the values passed in.
It also makes sense to test for validity inside the method because it keeps the logic all in one place and can be then the validity checking code is not repeated by all the classes that use this method, keeping your code nice and DRY (Don't Repeat Yourself).

Usually you can test for values being positive, not null, certain values and then use the @throw tag to document the restrictions to this method. Popular exceptions to throw are illegalArguementException, NullPointerException and indexOutOfBounds, this exceptions tend to do exactly what they say on the tin and anyone using your class will know what to expect.

There are some occasions that you can't check for validity but most cases you can probably validate the parameters passed in and this small amount of work will hopefully stop any bugs occurring inside or from using the method. I have found that I have been validating the parameters more now that I have been writing more unit tests. When I am writing a unit test I think more about the restrictions I should place on the parameters values