AUTOSAR C++14 Rule A15-0-2
At least the basic guarantee for exception safety shall be provided for all operations. In addition, each function may offer either the strong guarantee or the nothrow guarantee
Since R2022a
Description
Rule Definition
At least the basic guarantee for exception safety shall be provided for all operations. In addition, each function may offer either the strong guarantee or the nothrow guarantee.
Rationale
To facilitate recovery from an exception while preserving the invariant of the relevant objects, programs must be designed to have exception safety. The C++ standard allows these levels of exception safety:
Basic Exception Safety: This level of exception safety requires that after raising an exception, the basic invariants of all objects are maintained in a valid state and no memory is leaked. If an operation has basic exception safety, then you can destroy or assign to an object after the operations, even if an exception has been raised. The operations in standard library offers at least basic exception safety.
Strong Exception Safety: This level of exception safety requires that after raising an exception, the state of the program remains as it was before the exception. Operations with strong exception safety either succeed or exit with an exception and have no effects on the program.
nothrow
: This level of safety requires that an exception cannot occur in an operation.
Without at least the basic exception safety, exceptions might corrupt the
state of a program or create memory leaks. The AUTOSAR C++14 standard requires that a
program must offer at least the basic exception safety for all operations, strong exception
safety for key operations, and nothrow
guarantee for some
operations.
Polyspace Implementation
Polyspace® raises a violation of this rule if any of these conditions are true:
An exception violates a class invariant: This condition is met if a non-
noexcept
member function attempts to raise an exception after modifying any of the fields in the class. For instance, Polyspace flags athrow()
statement or anew
statement if they are used after modifying the internal state of a class.An exception leaves dynamic memory in an invalid state: This condition is met if an exception is raised without deallocating the dynamic memory that is already allocated. For instance, Polyspace flags an exception raising statement if it is outside a
try
block or inside acatch
block and the allocated resources are not deallocated before the statement. Exception raising statements might include:A
throw
statementCalls to functions containing
throw
statementsCalls to constructors containing
throw
statements.
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, Partially automated |
Version History
Introduced in R2022a