MISRA C++:2023 Rule 18.3.1
There should be at least one exception handler to catch all otherwise unhandled exceptions
Since R2024b
Description
Rule Definition
There should be at least one exception handler to catch all otherwise unhandled exceptions. 1
Rationale
When an exception remains unhandled, the compiler might invoke the function
          std::terminate(), which terminates the program abruptly. The abrupt
        termination does not invoke any exit handlers, does not call the destructors of the
        constructed objects, and does not unwind the stack.
Exceptions that are unhandled might result in issues such as memory leaks, security vulnerability, and other unintended behaviors. Poorly designed exception handling process might make your program vulnerable to denial-of-service attacks.
Design the exception handling in your code to handle expected and unexpected exceptions.
        Call functions that are not noexcept in try blocks.
        Handle the exceptions that these functions might raise by using matching
          catch() blocks. Include a catch-all block in
          main() to handle unexpected exceptions.
Polyspace Implementation
        Polyspace® reports a violation when a function that is called in
          main() raises an exception and the exception is not handled.
          Polyspace highlights the location in the function body where the unhandled exception is
        raised and flags the call to the function in main(). For
          instance:
void foo(){
    throw std::exception(); //Uncaught exception
}
int main(){
    foo(); //Defect
    return 1;
} std::bad_alloc raised
        by a new operator remains unhandled.Troubleshooting
If you expect a rule violation but Polyspace does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.
Examples
Check Information
| Group: Exception Handling | 
| Category: Advisory | 
Version History
Introduced in R2024b
1 All MISRA coding rules and directives are © Copyright The MISRA Consortium Limited 2021.
The MISRA coding standards referenced in the Polyspace Bug Finder™ documentation are from the following MISRA standards:
- MISRA C:2004 
- MISRA C:2012 
- MISRA C:2023 
- MISRA C++:2008 
- MISRA C++:2023 
MISRA and MISRA C are registered trademarks of The MISRA Consortium Limited 2021.