Page History

Exceptions should only be used only to denote exceptional conditions. They ; they should not be used for ordinary control flow purposes. Failure to follow this advice complicates both security analysis and debugging, can result in abnormal control flow and can cause performance degradation. Catching a generic object such as Throwable is likely to catch unexpected errors; see  ERR08-J. Do not catch NullPointerException or any of its ancestors for examples. When a program catches a specific type of exception, it does not always know from where that exception was thrown. Using a catch clause to handle an exception that occurs in a distant known location is a poor solution; it is preferable to handle the error as soon as it occurs—or to prevent it if possible.

The nonlocality of throw statements and corresponding catch statements can also impede optimizers from improving code that relies on exception handling. Relying on catching exceptions for control flow also complicates debugging because exceptions indicate a jump in control flow from the throw statement to the catch clause. Finally, exceptions need not be highly optimized, as it is assumed that they are thrown only in exceptional circumstances. Throwing and catching an exception frequently has worse performance than handling the error with some other mechanism.

Noncompliant Code Example

This noncompliant code example attempts to concatenate the string processed elements of the array values, storing the result as the first element. strings array:

String values[] = new String[3];
values[0] = "value1";
values[1] = "value2";
values[2] = "value3";
	
int i;
values[1] = null; // gets null value

public String processSingleString(String string) {
  // ...
  return string;
}
public String processStrings(String[] strings) {
  String result = "";
  int i = 0;
  try {
  i = 0;
 while while(true) {	      
   
   result values[0] = values[0]result.concat(processSingleString(valuesstrings[i + 1]));
 // Concatenate and store in values[0]  
    i++;
    }
  } catch (ArrayIndexOutOfBoundsException e) {
  i = 0; // Attempts to initialize i to 0
} catch (NullPointerException npe) {
  // Ignores
}
Ignore, we're done
  }
  return result;
}

This code It uses an ArrayIndexOutOfBoundsException to detect the end of the array and reinitialize the value of variable i to 0 in the catch block. However, when some element of the array is null, a NullPointerException results. This exception is caught and ignored, a violation of guideline EXC15-J. Do not catch NullPointerException. Consequently, the variable i fails to be reinitialized.

The purpose of exception handling is to detect and recover from exceptional conditions, rather than to transfer control flow. Further, the exception-based idiom is slower than the standard non-exceptional code. It also prevents optimizations that the JVM would otherwise perform.

. Unfortunately, since ArrayIndexOutOfBoundsException is a RuntimeException, it could be thrown by processSingleString() without being declared in a throws clause. So it is possible for processStrings() to terminate prematurely before processing all of the strings.

Compliant Solution

This compliant solution uses a standard for loop to concatenate the strings.

public String valuesprocessStrings(String[] =strings) {
 new String[3];
values[0] = "value1";
values[1]  result = "value2";
values[2] = "value3";

int i;
for (int i = 10; i < valuesstrings.length; i++) {
  values[0]  result = values[0]result.concat(values processSingleString( strings[i]));
  }
i  =return 0; // Initialize i to 0 after operation

...

result;
}

This code need not catch ArrayIndexOutOfBoundsException because it is a runtime exception, and such exceptions indicate programmer errors, which are best resolved by fixing the defect.

Applicability

Use of exceptions for any purpose other than detecting and handling exceptional conditions complicates both security program analysis and debugging, and can cause performance degradation.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website, degrades performance, and can increase maintenance costs.

Bibliography

...

...

...

...

Image Added Image Added Image Added|AA. Bibliography#Bloch 01]\] Item 39: "Use exceptions only for exceptional conditions" \[[JLS 2005|AA. Bibliography#JLS 05]\]ERR01-J. Use a class dedicated to reporting exceptions      06. Exceptional Behavior (EXC)      ERR03-J. Use a logging API to log critical security exceptions