Catching NullPointerException vs Fixing the Root Cause
Fast recall
Quick revision
Core answer
NullPointerException around a broad block is usually a code smell because it cannot tell an expected missing value from an unrelated null bug in that block. Define the null contract and handle absence before dereferencing, or validate required values. A narrow catch is reasonable only when a specific API explicitly uses NPE as part of a contract and the caller can handle that exact failure.Code quality mindset — does the candidate fix problems or mask them with exception handling
Wrapping code in try-catch NullPointerException when the real fix is to not have null in the first place
Explain Optional as the modern Java approach to nulls, and Objects.requireNonNull for fail-fast validation at method entry points
Interview-ready guide
Interview answer
Catching NullPointerException around a large block is usually wrong because the catch cannot identify which expression was null and may hide a separate bug. I handle a known nullable value explicitly before dereferencing it, validate required arguments, and use Optional where it makes a return contract clearer.
Java does not make every ordinary reference non-null by default, so the project must express that through API design, annotations, and tests. I would catch NPE only in a very narrow adapter if a documented API deliberately uses that exception for the exact condition I am translating.
Catching NullPointerException vs Fixing the Root Cause
Direct Answer
Catching NullPointerException around a broad block is usually a code smell because it cannot tell an expected missing value from an unrelated null bug in that block. Define the null contract and handle absence before dereferencing, or validate required values. A narrow catch is reasonable only when a specific API explicitly uses NPE as part of a contract and the caller can handle that exact failure.
Common Mistakes & Pitfalls
- Catching NPE as Validation: Wrapping code in try-catch
NullPointerExceptionto check if an object is null — this is wildly inefficient compared toif (obj != null)and semantically wrong because you're treating a bug as expected flow. - Returning Null from Methods: Having methods return null to signal "not found" instead of returning
Optional— this forces every caller to remember to null-check, leading to NPE bugs scattered throughout the codebase. The method signature doesn't communicate that absence is possible. - Defensive Null Checks Everywhere: Adding
if (obj != null)before every single object use because you don't trust your code — this indicates missing validation at entry points. Fix the root cause by ensuring nulls can't enter your system rather than checking everywhere.
Check your understanding
Answer these without looking back at the article.
- What is Objects.requireNonNull and when should you use it?
- How does Optional help prevent NullPointerException?
- What is the 'null object pattern' as an alternative to null checks?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.