1. Topics
  2. Throwing exceptions in destructors

Throwing exceptions in destructors

richard.furse@...
 

Hi there – I’m just taking a look through some of the OpenMAMA code and have a question. Is this the right place it?

 

The code I have (OpenMAMA 2.2.1.1) contains the following:

 

  MamaTransport::~MamaTransport (void)

    {

        if (mPimpl)

        {

        if ( mamaInternal_getCatchCallbackExceptions() && mPimpl->mCallback)

        {

          delete mPimpl->mCallback;

        }

            if (mPimpl->mDeleteCTransport)

            {

                mamaTry (mamaTransport_destroy (mTransport));

            }

            delete mPimpl;

            mPimpl = NULL;

        }

    }

 

Won’t this throw an exception and risk crashing if mamaTransport_destroy() fails? I can see similar code in other destructors, so I’m probably missing something.

 

Thanks,

 

--Richard

 



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

Glenn McClements <gmcclements@...>
 

Hi Richard,
Yes, this is the right place for those kind of questions. 

As a rule the mamaTry macro is called in the C++ wrapper before every call to the C layer, to translate the C return code to an exception on error conditions. However you are quite right in pointing out that this is dangerous practice in a destructor. 

In reality, in existing MAMA deployments this hasn't been an issue as the mama<object>_destroy() functions can not generally fail when called from the C++ wrapper. As more third party bridges are developed for OpenMAMA however this may become an issue. 

If you want to file a bug around this please do, at http://bugs.openmama.org 

Even better, if you wish to submit a patch for it then details for patch submission are below are at

Glenn 

From: <richard.furse@...>
Date: Tue, 13 Nov 2012 14:01:45 +0000
To: <Openmama-dev@...>
Subject: [Openmama-dev] Throwing exceptions in destructors

Hi there – I’m just taking a look through some of the OpenMAMA code and have a question. Is this the right place it?

 

The code I have (OpenMAMA 2.2.1.1) contains the following:

 

  MamaTransport::~MamaTransport (void)

    {

        if (mPimpl)

        {

        if ( mamaInternal_getCatchCallbackExceptions() && mPimpl->mCallback)

        {

          delete mPimpl->mCallback;

        }

            if (mPimpl->mDeleteCTransport)

            {

                mamaTry (mamaTransport_destroy (mTransport));

            }

            delete mPimpl;

            mPimpl = NULL;

        }

    }

 

Won’t this throw an exception and risk crashing if mamaTransport_destroy() fails? I can see similar code in other destructors, so I’m probably missing something.

 

Thanks,

 

--Richard

 



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
_______________________________________________ Openmama-dev mailing list Openmama-dev@... https://lists.openmama.org/mailman/listinfo/openmama-dev

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

richard.furse@...
 

Thanks!

 

I’m probably misreading the code, but won’t the MamaQueue destructor throw if there are any open events? This seems like a potentially common situation if there’s a stack unwind happening because of an exception thrown in other parts of the application, which is also a situation where a crash is more or less guaranteed on the second throw?

 

Best wishes,

 

--Richard

 

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: 14 November 2012 17:57
To: Furse, Richard (EQ/UK)
Cc: Openmama-dev@...
Subject: Re: [Openmama-dev] Throwing exceptions in destructors

 

Hi Richard,

Yes, this is the right place for those kind of questions. 

 

As a rule the mamaTry macro is called in the C++ wrapper before every call to the C layer, to translate the C return code to an exception on error conditions. However you are quite right in pointing out that this is dangerous practice in a destructor. 

 

In reality, in existing MAMA deployments this hasn't been an issue as the mama<object>_destroy() functions can not generally fail when called from the C++ wrapper. As more third party bridges are developed for OpenMAMA however this may become an issue. 

 

If you want to file a bug around this please do, at http://bugs.openmama.org 

 

Even better, if you wish to submit a patch for it then details for patch submission are below are at

 

Glenn 

 

From: <richard.furse@...>
Date: Tue, 13 Nov 2012 14:01:45 +0000
To: <Openmama-dev@...>
Subject: [Openmama-dev] Throwing exceptions in destructors

 

Hi there – I’m just taking a look through some of the OpenMAMA code and have a question. Is this the right place it?

 

The code I have (OpenMAMA 2.2.1.1) contains the following:

 

  MamaTransport::~MamaTransport (void)

    {

        if (mPimpl)

        {

        if ( mamaInternal_getCatchCallbackExceptions() && mPimpl->mCallback)

        {

          delete mPimpl->mCallback;

        }

            if (mPimpl->mDeleteCTransport)

            {

                mamaTry (mamaTransport_destroy (mTransport));

            }

            delete mPimpl;

            mPimpl = NULL;

        }

    }

 

Won’t this throw an exception and risk crashing if mamaTransport_destroy() fails? I can see similar code in other destructors, so I’m probably missing something.

 

Thanks,

 

--Richard

 

 

This e-mail (including any attachments) is confidential, may contain

proprietary or privileged information and is intended for the named

recipient(s) only. Unintended recipients are prohibited from taking action

on the basis of information in this e-mail and must delete all copies.

Nomura will not accept responsibility or liability for the accuracy or

completeness of, or the presence of any virus or disabling code in, this

e-mail. If verification is sought please request a hard copy. Any reference

to the terms of executed transactions should be treated as preliminary only

and subject to formal written confirmation by Nomura. Nomura reserves the

right to monitor e-mail communications through its networks (in accordance

with applicable laws). No confidentiality or privilege is waived or lost by

Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is

a reference to any entity in the Nomura Holdings, Inc. group. Please read

our Electronic Communications Legal Notice which forms part of this e-mail:

_______________________________________________ Openmama-dev mailing list Openmama-dev@... https://lists.openmama.org/mailman/listinfo/openmama-dev


Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

1 - 3 of 3