Hi Folks,
While debugging an application crash in a client program using qpid c++ API, I
traced the root cause of the error to the fact that an internal exception
(qpid::Exception) which is not exposed in the API was thrown. The exception
was in Mutex.h:116 locking code. I had coded an error recovery part of the
code and looks like:
// qpid::messaging::Connection m_conn;
// qpid::messaging::Session m_session
try
{
if (m_session.hasError())
{
m_session.close();
m_conn.close();
LOG(WARNING) << "Session has errors, recreating...";
m_conn.open();
m_session = m_conn.createSession();
}
}
catch(std::exception const& ex)
{
..
}
catch(...)
{
..
}
Exception is not caught in both the catch() blocks.
This is because there are places in the control flow where a Mutex object is
locked but the internal exception thrown is not captured. This leads to leak of
internal exception and since it is not exposed in the API, gcc cannot get its
typeinfo for exception handling and terminate() gets called. Since the issue
is with the QPid API, I am powerless to prevent crashes in my application.
Using two exception hierarchies and leaking internal exceptions is bug prone
and I think we should expose all the exception types (including internal) in
the API so as to not crash the clients using the API. What is the consensus
here on exposing ALL the exceptions qpid client API might possibly throw? Or am
I missing something?
Cheers
Venkatesan
Confidentiality Note: This e-mail and any attachments are confidential and may
be protected by legal privilege. If you are not the intended recipient, be aware
that any disclosure, copying, distribution or use of this e-mail or any
attachment is prohibited. If you have received this e-mail in error, please
notify us immediately by returning it to the sender and delete this copy from
your system. Thank you for your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
