Does Defensive Programming Deserve Such a Bad Name?

The other day I went to an hour's talk on erlang, merely as an observer; I know nothing about erlang except that it does sound interesting and that the syntax is... well... unusual. The talk was given to some Java programmers who had recently learnt erlang and was a fair critic about their first erlang project, which they were just completing. The presenter said that these programmers needed to stop thinking like Java programmers and start thinking like erlang programmers¹ and in particular to stop programming defensively and let processes fail fast and fix the problem.

Now, apparently, this is good practice in erlang because one of the features of erlang, and please correct me if I'm wrong, is that work is split into supervisors and processes. Supervisors supervise processes, creating them, destroying them and restarting them if required. The idea of failing fast is nothing new and is defined as the technique to use when your code comes across an illegal input. When this happens your code just falls over and aborts the point being that you fix the supplier of that input rather than your code. The sub-text of what the presenter said is that Java and defensive programming is bad and fail-fast if good, which is something that really needs closer investigation.

Dealing with Null Return Values

One of the things most of us do is to return null from their methods without questioning the validity of the technique. It should be widely excepted, but isn’t, that returning null is a bad idea as it forces any and all client code to constantly check method return values and take special action when they are null. Not only does your client code need to constantly check for null there is also the increased risk of a NullPointerException as it’s easy to miss a out a check altogether, which from experience, is a common occurrence.