Rule Definition
Catching the Exception class directly means that the try/catch will process all the exceptions in the same way: RuntimeException will be processed in the same way as application specific exceptions such BankingException or CredentialException. This will prevent the application from carrying out the specific recovery process that is needed and as a consequence will threaten both application robustness and security. For example, each exception related to resource allocation whose catch does not explicitly release the resource might create a resource leak. When such a leak occurs on a limited set of available resources, such as the database connection, the application can then become unusable because resources cannot be allocated any more. The application also becomes difficult to support and run in production as root-cause analysis is made more difficult. The support teams might not even be aware that something went wrong (by catching Exceptions, RuntimeException might not be visible any more).

Remediation
Always Subclass Exception and use the Subclassed Classes with appropriate and specific recovery code.

Violation Code Sample

try
{ ,,, }
catch (Exception /*e*/) // <= VIOLATION
{ ,,, }

Fixed Code Sample

" Hide
try
{ ,,, }
catch (SpecificException /*e*/)
{ ,,, }

Exception-Handling Antipatterns by Tim McCune http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html Best Practices for Exception Handling http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html Catching and Throwing Standard Exception Types http://msdn2.microsoft.com/en-us/library/ms229007(VS.80).aspx Warren, Nigel, and Bishop, Philip. Java in Practice. Addison-Wesley, 1999, p. 68. CISQ rule: ASCRM-CWE-396.