1

Are there any scenarios where we should not write defensive checks for null?

Should we write defensive code or check for NULL every time we have passed a parameter or received a value back from a method?

Will this put an extra burden on the compiler?

Improve this question
6
  • What is your question?
    – CodeCaster
    Dec 6, 2013 at 8:08
  • 1
    Its there in Title "Should we always write Defensive check in code?"
    – Hemant Kothiyal
    Dec 6, 2013 at 8:10
  • 3
    The answer is "it depends", and is too broad to answer. See How necessary is it to follow defensive programming practices for code that will never be made publicly available? an Defensive Programming Techniques for some great pointers. "Is that will make extra burden for compiler? etc" isn't really a concrete, answerable question.
    – CodeCaster
    Dec 6, 2013 at 8:12
  • 2
    I agree with @CodeCaster - it depends. I see a lot of "defensive" code that does "if (fred != null) { fred.doSomethingVital());}" but does not take any action if fred IS null. All this is defending against is a null reference - it doesn't defend the application at all if the call to fred.doSomethingVital() is actually key to the business operation the application is supporting. In this case it would probably be safer to not check the null reference - at least the code will fail quickly and noisily.
    – DaveHowes
    Dec 6, 2013 at 8:38
  • I think this depends on how nulls are used in your codebase. If they're a valid output to functions, then yes. If they're representative of a failure state, then the question becomes "can I meaningfully recover from this?", just like it would be with exceptions. Defensively checking for nulls to hide failures earlier in the codebase is just asking for difficult to debug errors.
    – Phoshi
    Dec 6, 2013 at 9:34

1 Answer 1

Reset to default
4

The ideal way to deal with null pointers is to forbid them by contract if a method cannot handle them. It depends on the language how well this is supported:

  • In Java, you can use the javax.validation.constraints.NotNull annotation (or similar ones provided by IDEs like IntelliJ and Eclipse) on any method parameter that is not allowed to be null. Unfortunately, this is not very portable.
  • In C#, you can use code contracts: Contract.Requires( x != null );
  • In C++, you can use references instead of pointers (but as soon as you're using smart pointers, you're out of luck)
  • In Ada, you can use a not null access type.
  • Some newer languages like Rust forbid null pointers by design.

I'd generally go for the contract approach rather than checking for null at runtime if possible. It enables earlier error discovery. Usually, contract-based null checking also generates a run-time check in addition to the compiler trying to deduce whether a parameter of a method call can violate the contract at compile-time.

Arguing that you trust the caller of your library is a bad idea, because you never know if the library will be re-used in another environment. Trust in callers will always harm code reusability.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.