That stack trace will tell you the exact line on which the exception occurs, in what source file; this will often suggest immediately what the problem is. If not, then tell us exactly where in this code the exception occurs, and we can advise you. Don't make us do all the work!
Alway provide null check for every object It' good coding practice
There are two sorts of null object:-
Those where you can expect some null values, eg the "left" and "right" values on a TreeSet, and
Those where you have forgotten to instantiate them. (Or have destroyed them by mistake.)
If your null object is the first sort, then your null check is (as Abhijit Ohal says) absolutely essential. If it is the second sort, then you need to go back and find where you have omitted to instantiate them. CR
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 ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.