ABSTRACT

It is generally a bad practice to catch NullReferenceException.

EXPLANATION

Programmers typically catch NullReferenceException under three circumstances:

1. The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullReferenceException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example: The following code mistakenly catches a NullReferenceException.


try {
MysteryMethod();
}
catch (NullReferenceException npe) {
}

REFERENCES

[1] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A6 Information Leakage and Improper Error Handling

[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A7 Improper Error Handling

[3] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3120 CAT II

[4] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 395

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.2, Requirement 6.5.6

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.5

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.7