Question

Consider this code:

x = Repo.GetX(13);
Services.Process(x);

I could check that x is null before processing it, or I could have Services.Process() throws an exception if X is null and use a try/catch block.

Which method is preferable?

(Or should I do both, just in the exceptional case that x becomes null somehow from the point of its retrieval to processing it?)

Answer 1

If you’re trying to decide between:

x = Repo.GetX(13);
try {
    Services.Process(x);
} catch (NullPointerException) {
    System.err.println('x is NULL');
}

or

x = Repo.GetX(13);
if (x != NULL) {
    Services.Process(x);
} else {
    System.err.println('x is NULL');
}

Then be aware that they don’t mean the same thing. The first one catches any NullPointerException thrown by Process. The second one only handles the case where x itself is NULL – if Process does x.foo().bar(), and x.foo() returns NULL, it isn’t handled.

You should decide between the two based on what errors you can handle.

In the case where Services.Process is documented to throw NullPointerException if and only if x is NULL, so that (assuming we believe the documentation) the two do mean the same thing, then I’d do the second one. That way, if the documentation is lies, and there’s a bug in Services.Process that makes it throw in some other situation, then we will not erroneously handle/report the exception as though x were NULL when in fact it is not.

So, catch and suppress an exception in two situations:

1. You know what (kind of thing) caused the error, and you know that you can handle that situation and continue regardless.
2. To protect some fairly outer level of code, like an event loop, from unexpected faults in the program or the environment. Ideally this should result in extensive logging, because either the system has failed to do what you expected (perhaps due to lack of resources or unmet dependencies), or else there’s a bug in someone’s code somewhere.

Don’t catch just because you know one situation that could cause the exception, and can handle that, when the same exception could be thrown for other reasons. I suppose you could do:

x = Repo.GetX(13);
try {
    Services.Process(x);
} catch (NullPointerException) {
    if (x == NULL) {
        System.err.println('x is NULL');
    } else {
        throw;
    }
}

But that seems to me needlessly verbose in this case: since we can check in advance whether x is null, we might as well. There are cases, though, where you catch an exception because it’s impossible or just silly to try to predict in advance whether it will occur or not:

String s = Rep.GetString(13);
try {
    f = Float.parseFloat(s);
    System.out.println('is a number');
} catch (NumberFormatException) {
    System.out.println('not a number');
}

We could check whether s is a valid number before calling parseFloat, but that would basically be doing the same work twice – checking a string is a valid float is pretty much the same as actually converting it. So it makes sense to catch this exception – we know what it means, we know what to do about it, we couldn’t realistically have prevented it from happening.

(Or you could use DecimalFormat.parse, which doesn’t throw at all)