It's right to check if a variable is equal/(not equal) to null? Depends on the context?

Question

Is this right?

Example code:

void foo(E param){

    if(param == null){
        // do this
    }else{
        // do that
    }
//...
}

First of all I read some posts where people where discussing about allowing variables to be null adds complexity to the software Best explanation for languages without null so I would like to make and effort and forget about this to try to answer this question.

The thought (My thought)

As a beginner my thought might be wrong but i Would like you to help me clear this up.

I think checking if a variable is null is correct depending on the context in which that variable is, let me explain with an example:

Bad use:

Our project have the Command pattern implemented and we have a set of instructions. Then we write in the console an instruction and we have to interpret it. We have an Interpreter Class which tries to parse that so if the interpreter cant find the appropiate instruction it returns null.

Code example:

public class Interpreter {

    public static final String LINE_SEPARATOR = System.getProperty("line.separator");
    private static final List<Instruction> listInstructions = loadInstructions();


    /**
     * Generates a new instruction according to the user input
     * @param line - A string with the user input
     * @return The instruction read from the given line. If the instruction is not correct, then it returns null.
     */
    public static Instruction generateInstruction(String line) throws WrongInstructionFormatException
    {
        Instruction instru = null;
        Iterator<Instruction> it = listInstructions.iterator();
        int i = 0;
        while(it.hasNext() && i <9 && instru == null)
        {
            try
            {
                instru = it.next().parse(line);
            }
            catch(WrongInstructionFormatException e)
            {

            }
            finally
            {
                i++;
            }
        }
        return instru;
     }
//...




public class MainClass
{
    /**
     * MainFunction
     */
        public void mainFuction()
        {

            Instruction instru;
            while(true)
            {
                instru = Interpreter.generateInstruction(orden);
                if(instru == null) <------
                    // Error.
                else
                    instru.execute();

            }

        }
  }

Well in this case I think we are implementing this wrong because the interpreter must not return null but an exception because in my opinion a variable in this context could never be null. I hope I'm being clear, if it is not then I would like to clarify later with your comments

Correct use: (EDITED)

The main class of our project has a set of attributes from which both can be instantiated or not. Depending on whether we have instantiated one, both or neither there will be a set of functions to perform one, two or no action.

public class MainClass extends Observable
{
    private A a;
    private B b; // This attribute allows you to start making a log in a txt file
    private C c; // This attribute allows you to start making a log in a DB

    public MainClass(A a){ //....}
    public MainClass(A a, B b) { // .....}
    public MainClass(A a, C c) { // .....}
    public MainClass(A a, B b, C c){ //.....}


    public void log(String update)
    {
        if(this.b != null) <-----
            // Save the update in the txt file
        if(this.c != null) <-----
            // Save the update in a db row
    }
}

Well, why is this right? I think is right because the attributes may have null value and not as in the previous case.

---

With this begins the discussion and I would like it to help other people if they had the same doubt.

Answer 1

The advice about nulls isn't not to check for them, but not to generate or allow them. Obviously, if you have nulls in your program, you will need to check for them.

In your second example, the way to follow the advice would be to find a way to implement your class so that it doesn't have nullable fields. Why does the class have optional attributes? What does it do with these attributes? Is there a way to structure the class (perhaps by breaking it into multiple classes) so that it does not have optional attributes?

In the second example, you are using the nullity of attributes in if tests. A standard thing to do in object-oriented design is to replace conditionals with polymorphism. Could you try that?

EDIT: Okay, here's how i'd solve the second case using polymorphism. I have removed the field a because it's not relevant in this case.

public class MainClass extends Observable {
    private final Collection<? extends LogDestination> logDestinations;

    public MainClass() {
        logDestinations = Collections.emptySet();
    }

    public MainClass(B b) {
        logDestinations = Collections.singleton(new TextFileLog(b));
    }

    public MainClass(C c) {
        logDestinations = Collections.singleton(new DatabaseLog(c));
    }

    public MainClass(B b, C c) {
        logDestinations = Arrays.asList(new TextFileLog(b), new DatabaseLog(c));
    }

    public void log(String update) {
        for (LogDestination logDestination : logDestinations) {
            logDestination.log(update);
        }
    }
}

interface LogDestination {
    public void log(String update);
}

class TextFileLog implements LogDestination {
    private final B b;

    public TextFileLog(B b) {
        this.b = b;
    }

    @Override
    public void log(String update) {
        // Save the update in the txt file
    }
}

class DatabaseLog implements LogDestination {
    private final C c;

    public DatabaseLog(C c) {
        this.c = c;
    }

    @Override
    public void log(String update) {
        // Save the update in a db row
    }
}

In abstract terms, what this is doing is pushing the only alternatives in the logic all the way up into the constructors, in the form of the choice of which LogDestinations to create. Once they're created, they can be treated completely uniformly, with polymorphism dispatching the general invocation to the specific method. Because there are different constructors for the different ways of setting up the object, there is no need for any conditional logic at all.

Answer 2

When it's a situation that is expected and/or recoverable, throwing an Exception vs returning null is almost entirely a question of style. The arguments you've laid out are good ones for a distinction, and if they make sense to you, then I say go for it.

That's not to say you should use Exceptions as a go-to flow-control tool, of course, but in situations like the one you're describing it sounds perfectly reasonable.

Answer 3

I have a program that has over 2000 classes. Assuming around 20 functions per class, that's 40,000 functions. A lot of them have only a few lines of code each (example: get/set functions). If each function checked for null arguments, etc, that's a lot of code devoted just to validation (a similar argument can be made for a lot of exceptions being handled). Also, if I were to check just for nulls, I might as well do full validation to ensure the (javadoc) contract is fulfilled. For example, iterating over a list of objects that is passed to the function, checking for nulls, range issues, etc. Note there will be performance issues with that approach.

Instead, I prefer to have an agreed upon policy that applies to the entire project that no functions are allowed to have null for arguments, or a return value that is null, unless specified in its javadoc (design by contract). It's the caller's responsibility to obey the (javadoc) contract and do any validation checks before calling my function. However, I would consider validation checks for constructors that take more than one argument (to ensure incomplete objects are not created), and a few functions that are overly complex on how they process the input arguments. Note the immediate caller of my function doesn't have to do the validation checks just before calling my function. Instead, at least one of the other functions somewhere along the call chain will need to do it. Note: I see on-line there is a lot of debate on the proper way to handle all this.