Re: Checking for null parameter

pek wrote:
So, is this all necessary? I mean, if A, Devil, Fire and Angel is null
and I know that they should not be, then that means that I have an
error in my code. There is no reason to explicity tell someone that
the object should not be null. If I do, I have to try catch almost 80%
of my code.

What do you think? If checking for null overkill or not?

A method must be coded to handle any input that can be sent to it. Otherwise it will break when it gets the wrong input.

What's the matter, is it too hard to copy-and-paste a try-catch block? If that's too much effort, change jobs and be a ditch digger.

The purpose of those try-catch blocks (and other logic to handle anomalous input) is to make it possible to fix the program when something bad happens.

Generally, design your algorithms so that undesired inputs are never passed in the first place. Your keywords to google are "algorithm invariants" and the Java 'assert' keyword. Warning: 'assert' is not for input checking! Its purpose is to enforce algorithm invariants.

What you have to check in private methods is different from what you have to check in public methods, on account of you completely control calls into private methods but not others.

If 'null' is a possible input, and you need to handle it differently from other values, then you absolutely, inexorably and inarguably must check for it.

Every time.

Without fail.

--
Lew
.