I have a third-party library that is sometimes throwing an exception. So I decided to wrap my code in a try/catch(...) so that I could log information about the exception occurring (no specific details, just that it happened.)
But for some reason, the code still crashes. On client computers, it crashes hard and the code to log the exception in the catch(...) never gets executed. If I run this on my debug / development machine I get the popup asking me if I want to debug. When I do this, it reports 0xC0000005: Access violation reading location XXX.
The odd thing is that with an older version of the third-party library, the exact same code DOES catch the exception, and the code to log the exception DOES execute. (I verified this within VS watching the same conditions occur.)
Here's the pseudo-code that is executing:
pObject = pSystem->Get_pObject()
pSystem->DoSomethingThatMightDestroy_pObject();
try
{
/* Call to third party function that is throwing exception */
pObject->SetValue(0);
}
catch (...)
{
__DEBUG_LOG_POSITION__; // A macro to log the current file line
// This code used to run in the older version of third-party library
// but the newer version just crashes before running the catch(...)
}
So I have two questions:
Is there some change in the way the third party might have compiled the library so that my code wouldn't be able to catch the exception? (Yes, there is a chance I can get the third party to make whatever fixes are necessary and recompile for me, if I know what to tell them.)
Assuming I can't get the third party to fix it, what can I do to catch these exceptions? I'm thinking along the lines of... is there some way for me to determine whether pObject was deallocated?