Tag Archives: error handling

Defensive null checking

Something I’ve often come across – and been guilty of myself – is the habit of programming in an overly defensive manner, specifically with regard to null checking of parameters. When writing a new function or method, I’ve often found myself immediately defending against null parameters, without even taking the time to think through the implications or what it even means. Such an example of code is as follows:

public String getFormattedDateString(String dateString, String dateFormat, String newDateFormat)
	{
		// Check for invalid arguments
		if (dateString == null || dateFormat == null || newDateFormat == null)
		{
			return null;
		}

		...
	}

At first glance, you might think to yourself that this code is reasonable; if null is provided as an argument, then how is it bad practice to simply return null┬áback in this case? However, if you start to ask yourself certain questions about what that means in terms of the function’s purpose, you might reconsider:

  • Is the method for public use or purely for internal use?

This is significant. I feel if a method is simply for internal use by you or your team and does not form part of some public module/API, there is no need to be overly defensive in terms of validating against nulls. If you own the method and understand the internals, you are fully aware of what it expects as input and thus know what to provide; it’s very different to the case where your method is open for public abuse.

  • Does the method signature suggest that the result is viable?

In our example, the method’s purpose is to return a formatted date and states very explicit requirements: you need to provide a suitable date along with its current format and a new format to use. This isn’t a search function where a not found (null) result may be expected, but rather a function where a valid result is expected provided the input is itself valid.

  • If an argument is invalid and you handle it, what does the result communicate to the caller?

In our case, what does returning null communicate to the caller? In some cases if you explicitly document that null is a possible result, the caller can manage this and deal with it accordingly; however, in a lot of cases where null shouldn’t be a suitable result, all the null does is delay a likely null pointer exception (NPE). And this is bad. I’m of the opinion that failing fast is good… it allows one to narrow down the bad code faster and prevents any subsequent errors from obscuring the original cause.

Looking at our example further, one might think that simply throwing an illegal argument exception might be the best bet.

public String getFormattedDateString(String dateString, String dateFormat, String newDateFormat)
	{
		// Check for invalid arguments
		if (dateString == null || dateFormat == null || newDateFormat == null)
		{
			throw new IllegalArgumentException("Please provide valid date, current format and new format strings." );
		}

		...
	}

Whilst I agree that this is a better solution, ask yourself: is throwing this exception more accurate than just allowing the NPE to happen in the first place? I think the illegal argument exception would be more appropriate if a given argument didn’t fit a requirement (such as an invalid date format). In our particular case, however, I feel unless you are going to return/throw something more useful than the NPE, just allow it to bubble up as it presents exactly what has happened.

One other benefit of avoiding this type of defensive programming is the reduction in code clutter which will ultimately help with readability as well as maintenance. Obviously, this post presents just one example and may not necessarily be applicable for all situations. Nonetheless, food for thought.

Advertisements