While working on enahncements on a project already in production, I had a very interesting conversation. Let me give a brief background – the core architecture is all in place and we need to build in new functionality. Of course, refactoring is being done along the road. In a specific scenario, I got into a conversation with a fellow architect on usage of “nulls” and “null checks”. The theme of the conversation was “Should a method return a null or an initialized instance of the class”. Let me take an example:
There is a service method that connects to a database loading records for all users in the system. In the DAO we are loading the recordset from the database and converting to an ArrayList of DTO (ValueObject). A sample code to map the a DTO generally is:
List<User> users = null;
for(int index = 0; index < recordSet.size(); index++)
{
User user = new User();
user.setFirstName(recordSet.getString(“firstName”);
user.setMiddleName(recordSet.getString(“middleName”);
user.setLastName(recordSet.getString(“lastName”); user.add(user);
}
return users;
I had an objection to this style of coding. The simple reason being, on the front-end, I had to put a check for null which was un-necessary. Hence, the other classes that were consuming the results had to write the following code:
List<Users> users = loadAll();
if(users != null)
{
/// do something
}
else
{
if(users.get(index).getMidleName() != null)
{
// show the middle name
}
else
{
// do not show the middle name
}
}
Now, consider a scenario with complex objects having lists all down the hierarchy. It means that before we access a property, we will have to provide a null check. Soon, this “do nothing” null check will become a headache. Someone has coded a null propogation somewhere and we can not trace it. We feel the easiest way is to put in a null check. In my given example, I would have my JSP strewen with null checks cluttering my code.
Unfortunately, this will not solve the real problem. A simple solution is to identify the code where a null reference can be introduced and handle it there. The rest will be happy about it.
More importantly, et us pause for a minute and ask ourselves – Is there something that the application can do, with an object refering to nothing? Let us go back to my example and see how is the application going to use the user list. We need the list of the users to display a report for the users listed. If no users are returned, the uer should see “No users exist”. The UI is no sure, what represents users – a null object or an initialized object with 0 size or an exception. This will mean that the developer consuming the method will have to write these multple conditions for a simple check.
We can do oe of the following:
1. Throwing a business exception that voilates a business logic can be an effective strategy. However, it largely depends on how do you use exceptions in applications. Remember, raising an exception is an expensive operation.
2. Alternatively, you can provide an Empty implementation of the object that can do something useful like logging an info or an error to the log system.
I am not a hugh fan of throwing an Exception, and also because it is expensive, I am exploring the second option. This changes my code to:
List<User> users = null;
for(int index = 0; index < recordSet.size(); index++)
{
User user = new User();
user.setFirstName(recordSet.getString(“firstName”));
if(recordSet.getString(“middleName”) == null) // You can also use StringUtils from apache.lang
{
user.setMiddleName(“”);
}
else
{
user.setMiddleName(recordSet.getString(“middleName”));
}
user.setLastName(recordSet.getString(“lastName”)); user.add(user);
}
if(users == null)
{
// throw new business exception
}
// else we return an initialized list.
return new ArrayList<User>();
This will change the UI code to:
List<Users> users = loadAll();
// code to show the middle name – if it does not exist, it will show up as blank.
The most evident benefits is – “No more if statements for null checks on the UI. Check is being pushed down in the call hierarchy. Hence, multiple methods calling the same method will not have to worry about nulls.”
The most important question is “Is this approach safe?” Nothing ever is. There is no reason for someone to code incorrectly. Of course, we can not on external libraries never to return null references, but when you write your own code, following this approach can lead to a less cluttered application and a better control over source code.
Remember: The approach is not always necessary, just ensure that the null reference should not be catastrophic.
