MISRA C++:2023 Rule 18.4.1
Description
Rule Definition
Exception-unfriendly functions shall be
noexcept. 1
Rationale
These functions are considered exception-unfriendly:
Destructors — Destructors can be called during the process of handling an exception that has already occurred. If the destructors themselves exit with an exception, the program terminates. Whether this termination releases the already allocated resources and unwinds the stack is implementation-dependent. Also, destructors of
staticor global objects can be called after the termination ofmain(). Any exceptions arising at that point from the destructors remains unhandled, resulting in an abnormal program termination.Copy constructors of exception objects — When throwing an exception, the program copy constructs the exception object. If an exception arises from the copy constructor of the exception object, this exception propagates, which is unexpected behavior. Exception handlers can also copy the exception object. If an exception arises when handlers copy the exception object, the program terminates abnormally.
Move constructors and move assignment operators — If the move constructor or move assignment operator of an object is not
noexcept, the standard library containers and algorithms can use copy operations instead of move operations. It is difficult to achieve strong exception safety if move operations are notnoexcept.Functions named
swap— The standard library functions and algorithms expectnoexceptimplementation of theswapfunctions. These functions and algorithms can behave abnormally if theswapfunctions are notnoexcept.Functions or constructors that initialize a non-
constexprglobal variables with static or thread storage duration — These functions are called before themain()function and any exception thrown by these functions cannot be handled, resulting in abnormal termination of the program.Functions and lambdas that are passed as arguments to an
extern "C"function — These functions or lambdas are expected to be invoked from C code that cannot handle exceptions.Functions passed as callbacks to
std::atexit,std::at_quick_exit, orstd::set_terminateas callback functions — An exception in any of these functions results in abnormal termination of the program.
Polyspace Implementation
The rule checker reports a violation of this rule if any of these conditions are true:
The copy constructor of a class is not declared
noexceptand an object of the class is later thrown as an exception.A class constructor or function that initializes a global variable is not declared
noexcept.A move constructor or move assignment operator is not declared
noexcept.A function named
swapis not declarednoexcept.A function or lambda is not declared
noexceptand is passed as an argument to anextern "C"function.A
noexceptfunction is passed as a callback function tostd::atexit,std::at_quick_exit, orstd::set_terminate.
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: Required |
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.