I like to “sigh” along with an engineer that works with me. We roll our eyes especially at Java programmers, but I’ve seen the same laziness exhibited by Perl, PHP and other scripting languages; however, it is especially noted with Java programmers.

Back in my younger days when I coded mostly in C, we had to not only manage our memory, but we had to do a lot of boundary checking and whatnot. Stack and buffer overflows were a common symptom of “programmer laziness.”

But newer languages like Java now check for this sort of thing, so if a user gives me an input string that is too long, the java.lang.String class, will just truncate it.

Having the language do such lovely things like boundary checking and memory management lulls many programmers into a false sense of complacency. For instance, consider this code example:

public byte[] myBlob(String s) {
    byte[] blobBytes = new byte[s.length()];
    for (int i = 0; i < blobBytes.length; i ++)
       blobBytes[i] = (byte)s.charAt(i);
    return blobBytes;
}

See anything wrong with this code? What if the s variable is null? You get an NPE … er, sorry, a null pointer exception. So what you say… it just means the caller has a problem that he has to solve. Actually, these sorts of bugs slide all the way to the customer, where a field tech engineer flies out to the customer site to see the stack trace— which incidently, ends in your method— and gives you a call at 4 in the morning.

While I’m up here, allow me to do a hand-stand on this soap box— NPE’s are quite useless. If calling your method with a null is incorrect, it would be better to throw a new, more helpful exception than to just let the NPE surface.

So boys and girls, even if you are writing the client that is calling your code, at least check your inputs on your public methods… Come back next week for another rant… er, tip.