Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.7
-
None
-
Windows
Description
While adding the FailoverUpdate object a problem in the .NET Binding's scheme of error handling showed up. This issue will document the original problem and show a proposed coding pattern to make it better.
Two versions of the FailoverUpdates constructor:
*****************
Original Version
*****************
FailoverUpdates::FailoverUpdates(Connection ^ connection) :
failoverupdatesp(new ::qpid::messaging::FailoverUpdates(*(connection->NativeConnection)))
{
}
This looks OK to me from a pure C++ standpoint. The problem comes from the environment in which this code runs. It is called by a managed C# or other .NET caller and it calls into the unmanaged C++ Qpid Messaging code. Using this code when the C++ code throws, the exception goes to a handler that does not understand what to do with it.
A. If the user has no try-catch in the .NET calling code then a popup box shows:
---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!
Program: ...\src\Debug\csharp.map.sender.vshost.exe
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
"in an unusual way"? What does that mean? This is not good.
*****************
Improved Version
*****************
FailoverUpdates::FailoverUpdates(Connection ^ connection)
{
System::Exception ^ newException = nullptr;
try
{ failoverupdatesp = new ::qpid::messaging::FailoverUpdates(*(connection->NativeConnection)); }
catch (const ::qpid::types::Exception & error)
if (newException != nullptr)
{ throw newException; }}
The idea is to catch the exception from native C++ and rethrow it as a System::Exception.
B. Now the user sees:
An unhandled exception of type 'Org.Apache.Qpid.Messaging.QpidException'
occurred in org.apache.qpid.messagingd.dll
Additional information: Connection has not yet been opened
(..\..\cpp\src\qpid\client\Connection.cpp:139)
--------
I think the beauty of using a member initialization list is overshadowed by the fact that the original version mishandles exceptions. I intend to replace all instances of the .NET binding's constructors with the same pattern.