Software Development: Returning Null and Null Checks

This past week I was looking over a number of merge requests and some of them had new methods declared with a return type of String (these are Java classes). With all of these methods if there is a logic issue or some unexpected behaviour then instead of returning an empty String object they all returned null. Personally this starts ringing alarm bells and waving red flags. Why is that you may ask?

If nulls are being returned, passed around to other methods, etc then the programmer will need to check before using that object (well they should anyway). There have been numerous times where I have seen programmers completely ignoring a null check for an object even though the method they used before to set that object could potentially return a null. With every one of these cases I politely leave a comment on the merge request, waiting until an update commit with the null checks are added before merging. Better safe than sorry.

Now am I being too cautious? I tend to lean towards the overly cautious side because it does not take much more lines of code and effort to ensure that the appropriate logging and checks are in place so that unexpected errors and problems with the software are not encountered by the user; plus it means that the software you are writing is safer. Let me know how you handle situations like this. Talking to some of the other programmers I know, they are split on the subject. Some don’t really care what is returned and don’t bother checking the object before use (those I call cowboy programmers), some don’t really care what is returned but do check before the object is used, and some care about what is returned and always check the object before use (I fall into this camp).

Potentially this problem is solved on a case by case basis. Is there a valid reason a null object should be returned? I’ll be doing some more reading about this to get a better understanding to ensure that I adhere to proper programming etiquette and safe programming.

Java Deprecation Annotation

An annotation that is near and dear to my heart; as someone who constantly evolves their classes it is vital that if I cannot remove some old methods and/or fields at a single moment, I correctly identify that they should no longer be used and a new method or field should be used instead. I have also been seeing it more and more the last couple of days on the open source projects that I am viewing (which is strange as this is not the first time I am thinking about a certain concept and then it appears everywhere).

The reason why I really appreciate the @Deprecated and @deprecated Java annotations are because as your classes evolve you sometimes have to signal to the developers working on the project that “hey this should no longer be used, it has been superseded by another method and you should use that one instead”. Both these annotations do just that.

@Deprecated vs @deprecated

If you take a quick look at the annotations then you may not see the difference. But having a capital letter ‘D’ instead of a lower case letter ‘d’ is important.

The @Deprecated annotation is to let the compiler know to generate a warning whenever your program is using the class, method or field that has the annotation.

The @deprecated annotation is specifically used for the Javadoc and notifies to the developer to not use the class, method or field and use the appropriate superseded one.

Generally I use both. @Deprecated to actually deprecate the class, method or field and then the @deprecated annotation in a comment to highlight which superseded class, method or field to use instead, and also very importantly note why the class, method or field was deprecated.

I have seen plenty of times only @Deprecated is used with no information as to what to use instead, which is slightly frustrating. It is always worth spending a small amount of time to correctly document why something has been deprecated and what to use instead, it makes everything much easier for you and everyone else.

Using @Deprecated

It is very simple to use the annotation.

To deprecate a class:

public class Person { ... }

To deprecate a method:

public class Person {
	public String getName() { ... }

To deprecate a field:

public class Person {
	private String name;

Using @deprecated

Just as important as deprecating a class, method or field I believe in documenting what to use instead and why the original class, method or field has become deprecated. This annotation is sometimes missed by many developers from the open source projects that I have looked at.

To document a deprecated class, method or field:

 * @deprecated
 * Replaced by {@link #Entity}
 * No longer valid as a Person objects are replaced by Entity objects.
public class Person { ... }

Official Documentation

For more information about the two annotations then take a look at the official Oracle documentation, here.