Use of NullPointerException Catch to Detect NULL Pointer Dereference

Draft Base
Structure: Simple
Description

Using a try-catch block for NullPointerException as a substitute for proper null checks is an anti-pattern. This approach masks the root cause of null pointer dereferences instead of preventing them, leading to unstable and difficult-to-debug code.

Extended Description

Developers sometimes catch NullPointerException for three main reasons, but only one is valid. The first, and most problematic, is using the catch block to handle an existing null dereference bug instead of fixing it with proper validation. The second is explicitly throwing the exception to signal an error, which is misleading as it's designed for runtime detection, not control flow. The only acceptable use is within a testing framework that intentionally generates invalid inputs to verify robustness. Relying on exception handling for normal program logic creates fragile code that obscures the actual source of null values. Instead, you should proactively prevent null dereferences by validating arguments, using optional types, or employing safe navigation operators provided by your language. This makes the code's intent clear, improves performance by avoiding expensive exception overhead, and results in more maintainable and predictable software.

Common Consequences 1
Scope: Availability

Impact: DoS: Resource Consumption (CPU)

Detection Methods 5
Automated Static Analysis - Binary or BytecodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
Dynamic Analysis with Manual Results InterpretationSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Framework-based Fuzzer
Manual Static Analysis - Source CodeSOAR Partial
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Manual Source Code Review (not inspections)
Automated Static Analysis - Source CodeHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Architecture or Design ReviewHigh
According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Potential Mitigations 1
Phase: Architecture and DesignImplementation
Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application.
Demonstrative Examples 1

ID : DX-202

The following code mistakenly catches a NullPointerException.

Code Example:

Bad
Java
java
References 2
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and MetricsNIST
07-11-2005
ID: REF-6
State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation
Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, and Rama S. Moorthy
07-2014
ID: REF-1479
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • 7 Pernicious Kingdoms
  • The CERT Oracle Secure Coding Standard for Java (2011)