Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by gnat, Joris Timmermans, kevin cline, Bart van Ingen Schenau, JeffO Dec 6 '13 at 13:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
What is your question? –  CodeCaster Dec 6 '13 at 8:08
1  
Its there in Title "Should we always write Defensive check in code?" –  Hemant Kothiyal Dec 6 '13 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 '13 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 '13 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 '13 at 9:34

1 Answer 1

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.

share|improve this answer

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