<![CDATA[MISRA Discussion Forums - 6.15 Exception handling (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 13:23:21 +0000 MyBB <![CDATA[Memory allocation when throwing an exception.]]> https://forum.misra.org.uk/showthread.php?tid=1442 Tue, 24 Jul 2018 12:15:31 +0000 apasternak]]> https://forum.misra.org.uk/showthread.php?tid=1442
While doing a memory audit of our framework for autonomous driving cars we realized that throwing any kind of exception dynamically allocates memory on compilers using the Itanium C++ ABI (notably gcc and clang). Further, throwing an exception may block for which is not acceptable for safety-critical real-time systems.

Neither Misra 2008 nor Autosar 14 or other guidelines forbid exceptions in safety-critical environments. What were the considerations when investigating this issue?

To solve this issue we created a library which replaces the dynamic memory allocation with a memory pool. This library is freely available here: https://github.com/ApexAI/static_exception

Any inputs or other approaches would be very welcome!

Best regards,

Andreas]]>
While doing a memory audit of our framework for autonomous driving cars we realized that throwing any kind of exception dynamically allocates memory on compilers using the Itanium C++ ABI (notably gcc and clang). Further, throwing an exception may block for which is not acceptable for safety-critical real-time systems.

Neither Misra 2008 nor Autosar 14 or other guidelines forbid exceptions in safety-critical environments. What were the considerations when investigating this issue?

To solve this issue we created a library which replaces the dynamic memory allocation with a memory pool. This library is freely available here: https://github.com/ApexAI/static_exception

Any inputs or other approaches would be very welcome!

Best regards,

Andreas]]> <![CDATA[Proverbially Playing the `Devil's Advocate' for Rule 15-1-2]]> https://forum.misra.org.uk/showthread.php?tid=581 Thu, 11 Sep 2008 18:46:48 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=581
Code:
class A {};
A NULL;
void f()
    {
    throw NULL;
    }
The very premise of the rationale for the rule is invalid. In this case a `throw NULL;' is not equivalent to `throw (0);' and is not a throwing of an integer expression.

Furthermore, the wording of the rationale is slightly incorrect:
Quote:throw(NULL) (equivalent to throw(0)) is never a throw of the null-pointer-constant ...
To quote ISO C++, 18.1, para. 4, (lib.support.types):
Quote:The macro NULL is an implementation-defined C++ null pointer constant in this International Standard
(4.10).
Granted, the referenced `4.10' states a null pointer constant has integer (not pointer) type. However, the macro is a null pointer constant.]]>
Code:
class A {};
A NULL;
void f()
    {
    throw NULL;
    }
The very premise of the rationale for the rule is invalid. In this case a `throw NULL;' is not equivalent to `throw (0);' and is not a throwing of an integer expression.

Furthermore, the wording of the rationale is slightly incorrect:
Quote:throw(NULL) (equivalent to throw(0)) is never a throw of the null-pointer-constant ...
To quote ISO C++, 18.1, para. 4, (lib.support.types):
Quote:The macro NULL is an implementation-defined C++ null pointer constant in this International Standard
(4.10).
Granted, the referenced `4.10' states a null pointer constant has integer (not pointer) type. However, the macro is a null pointer constant.]]> <![CDATA[Misleading statements in Rule 15–1–3.]]> https://forum.misra.org.uk/showthread.php?tid=553 Mon, 14 Jul 2008 20:21:55 +0000 James Widman]]> https://forum.misra.org.uk/showthread.php?tid=553
In the Rationale for Rule 15–1–3, we have:
Quote:However, syntactically, there is nothing to prevent throw; being used outside a catch handler, where there is no exception object to re-throw. This may lead to an implementation-defined program termination.
There are a couple of problems with this.

First, it't not quite right to refer to a *place* where an exception object can be re-thrown so much as it is to refer to a *time* when such an object can be re-thrown. Refer to 15.1 except.throw. For example, this program:

Code:
extern "C" int printf( const char*, ... );

struct A
    {
    A() { (void)printf( "::A::A()\n" ); }
    ~A() { (void)printf( "::A::~A()\n" ); }
    };

void rethrow() { throw; }

void f(  ) {
    try {
        throw A();
    }
    catch (A& p) {
        (void)printf( "entering f()'s handler...\n" );
        rethrow();
        (void)printf( "exiting f()'s handler without throwing...\n" );
    }
}

int main (void) {
    try {
        f();
    }
    catch( A& p ) {
        (void)printf( "exiting main()'s handler...\n" );
    }
    return 0;
}

... yields this output:
Code:
::A::A()
entering f()'s handler...
exiting main()'s handler...
::A::~A()
(This is specified in the Standard; this is not implementation-defined behavior.)

So the text "where there is no exception object to re-throw" should be changed to something like, "where control could pass at a time when there is no exception object to re-throw".

Second, the rationale text ends with, "This may lead to an implementation-defined program termination."

When you squint at the standardese in just the right way, this sentence is true: it *may* lead to implementation-defined behavior, but only if the non-libary part of the program does not set a terminate_handler. But given the normative text in 15.5.1 except.terminate, it would be much better to change this sentence to:
Quote:If an empty throw is used at a time when there is no exception object to re-throw, std::terminate() is implicitly called. (The stack is not unwound before this call.)
]]>
In the Rationale for Rule 15–1–3, we have:
Quote:However, syntactically, there is nothing to prevent throw; being used outside a catch handler, where there is no exception object to re-throw. This may lead to an implementation-defined program termination.
There are a couple of problems with this.

First, it't not quite right to refer to a *place* where an exception object can be re-thrown so much as it is to refer to a *time* when such an object can be re-thrown. Refer to 15.1 except.throw. For example, this program:

Code:
extern "C" int printf( const char*, ... );

struct A
    {
    A() { (void)printf( "::A::A()\n" ); }
    ~A() { (void)printf( "::A::~A()\n" ); }
    };

void rethrow() { throw; }

void f(  ) {
    try {
        throw A();
    }
    catch (A& p) {
        (void)printf( "entering f()'s handler...\n" );
        rethrow();
        (void)printf( "exiting f()'s handler without throwing...\n" );
    }
}

int main (void) {
    try {
        f();
    }
    catch( A& p ) {
        (void)printf( "exiting main()'s handler...\n" );
    }
    return 0;
}

... yields this output:
Code:
::A::A()
entering f()'s handler...
exiting main()'s handler...
::A::~A()
(This is specified in the Standard; this is not implementation-defined behavior.)

So the text "where there is no exception object to re-throw" should be changed to something like, "where control could pass at a time when there is no exception object to re-throw".

Second, the rationale text ends with, "This may lead to an implementation-defined program termination."

When you squint at the standardese in just the right way, this sentence is true: it *may* lead to implementation-defined behavior, but only if the non-libary part of the program does not set a terminate_handler. But given the normative text in 15.5.1 except.terminate, it would be much better to change this sentence to:
Quote:If an empty throw is used at a time when there is no exception object to re-throw, std::terminate() is implicitly called. (The stack is not unwound before this call.)
]]>