Originally posted by abhijit Ohal:
Alway provide null check for every object It' good coding practice
No, it's not.
Of course,
you should include null checks when a variable can validly be null, but you should not burden your code with loads of null checks for variables that should never be null. You will make your code harder to read and maintain and slower to execute.
If you skip steps when a variable is null that should not be so, you may also mask the true cause of problems, making debugging difficult. The bug may only manifest itself a lot later, in a confusing way. If you'd simply allowed the program to throw NullPointerException, the stack trace would have told you immediately what was wrong.
The idea of adding loads of null checks sounds like a misinterpretation of the principle of "defensive programming". Yes, you should defend your code against all situations that can validly occur. But should not code to make it carry on regardless when a bug has manifested itself; you want the code to blow up immediately and obviously, so the bug is easily spotted and easily fixed. Early bug detection saves a massive amount of time and money.
One thing that you may like to consider is using assertions (the assert keyword) to check for nulls in variables that should not be null. This can achieve the best of both worlds, by achieving early bug detection during development and internal
testing, but allowing best-effort-to-continue to be made in released code. Don't go mad with assertions, though; your code still needs to be readable and maintainable.
[ July 14, 2006: Message edited by: Peter Chase ]