Difference between revisions of "Overly-Broad Catch Block"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
{{Template:Vulnerability}}
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
The catch block handles a broad swath of exceptions, potentially trapping dissimilar issues or problems that should not be dealt with at this point in the program.
 
  
 
==Description==
 
==Description==
 +
 +
The catch block handles a broad swath of exceptions, potentially trapping dissimilar issues or problems that should not be dealt with at this point in the program.
 +
  
 
Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.
 
Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.
  
==Examples ==
+
 
 +
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
==Examples==
  
 
The following code excerpt handles three types of exceptions in an identical fashion.
 
The following code excerpt handles three types of exceptions in an identical fashion.
Line 41: Line 54:
  
 
However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.
 
However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.
 +
==Related [[Attacks]]==
  
==Related Threats==
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
==Related Attacks==
 
  
==Related Vulnerabilities==
+
==Related [[Vulnerabilities]]==
  
==Related Countermeasures==
+
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
  
==Categories==
+
==Related [[Controls]]==
  
[[Category:Implementation]]
+
* [[Control 1]]
 +
* [[Control 2]]
  
[[Category:Error Handling Vulnerability]]
 
  
[[Category:Java]]
+
==Related [[Technical Impacts]]==
  
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
 +
TBD
 +
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Implementation]]
 +
[[Category:Error Handling Vulnerability]]
 +
[[Category:Java]]
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]

Revision as of 12:55, 28 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article includes content generously donated to OWASP by Fortify.JPG.

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Last revision (mm/dd/yy): 09/28/2008

Vulnerabilities Table of Contents

ASDR Table of Contents

Contents


Description

The catch block handles a broad swath of exceptions, potentially trapping dissimilar issues or problems that should not be dealt with at this point in the program.


Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.


Risk Factors

TBD

Examples

The following code excerpt handles three types of exceptions in an identical fashion.

	  try {
		doExchange();
	  }
	  catch (IOException e) {
		logger.error("doExchange failed", e);
	  }
	  catch (InvocationTargetException e) {
		logger.error("doExchange failed", e);
	  }
	  catch (SQLException e) {
		logger.error("doExchange failed", e);
	  }

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

	  try {
		doExchange();
	  }
	  catch (Exception e) {
		logger.error("doExchange failed", e);
	  }

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References

TBD