CWE-396

Declaration of Catch for Generic Exception. [Error-Conditions, Insufficient-Control-Flow-Management]

Required inputs: IR

Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. 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 a language'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.

Demonstrative Examples

Example 1

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

Example Language:Java (Unsupported language for documentation only)
    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.

Excerpts from CWE [https://cwe.mitre.org], Copyright (C) 2006-2026, the MITRE Corporation. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
catch_all	Use of catch(…).	None	False
catch_std_exception	Catching std::exceptions is too general.	None	False

Options

• This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity

• The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

allow_in_extern_c_functions

allow_in_extern_c_functions : bool = False

Whether to allow a catch-all in extern C functions.

 

allow_in_functions_matching

allow_in_functions_matching : typing.Pattern[str] | None = None

If not None, a re.compile()ed object where functions whose qualified name matches the regex are allowed to contain catch-alls.

 

allow_in_main

allow_in_main : bool = False

Whether to allow a catch-all in the main() function.

 

allow_in_thread_main

allow_in_thread_main : bool = False

Whether to allow a catch-all in thread-main functions.

 

allow_rethrow

allow_rethrow : bool = False

Whether to allow a catch-all with a re-throw.

 

autosar_exception_model

autosar_exception_model

Type: bauhaus.ir.autosar.exceptions.autosar_exceptions.AutosarExceptionModel

Default: <bauhaus.ir.autosar.exceptions.autosar_exceptions.AutosarExceptionModel object at 0x7f6f1d938d90>

The default model for what counts as an checked / unchecked exception.

 

disallow_std_exception

disallow_std_exception : bool = False

Whether to consider catching the literal std::exception as a catch-all.