Exception handling

[jeffchen]

Hi,

I just got an idea about the exception handling. I am currently implementing a program that will use some third party dll, COM object. When these dll generate a error, usually my program will get an unhandled exception and in my exception handling code I can do little but write some debug information and let the program quit.

I think if I can know which thread that caused the exception from the exception address and other information, maybe I can terminate the thread from my exception handling code and resume from the exception.

My question is how do I know which thread caused the exception from the exception related information, such as fault address, context, etc ?

[Igor Vartanov]

Originally posted by jeffchen
I just got an idea about the exception handling. I am currently implementing a program that will use some third party dll, COM object. When these dll generate a error, usually my program will get an unhandled exception and in my exception handling code I can do little but write some debug information and let the program quit.

You can do much more useful thing - place a dll function calls in try-catch or __try-__except braces and find out a reason in debugger (I hope you set your VS debugger as default debugger)

I think if I can know which thread that caused the exception from the exception address and other information, maybe I can terminate the thread from my exception handling code and resume from the exception.

And I think the thread could be only one - the your app thread calling that dll functions. You have to know a dll function code always performed in a context of thread it calling (if the dll code doesn't create another thread).

My question is how do I know which thread caused the exception from the exception related information, such as fault address, context, etc ?

My question is WHY DON'T YOU USE A COMMON WAY BUT GONNA KILL THINGS AROUND YOU DON'T QUITE UNDERSTAND? Ain't you read anything about exception handling?

[jeffchen]

Thanks Igor Vartanov.

Maybe I did not make it very clear. The DLL and the COM component used in my program is developed by third party companies and I can not put a try catch into their code for sure. A similar example may be the plugins for Internet explorer, such as third party toolbar, BHO etc. They have their own message loop/thread and may throw exception from somewhere that my program can not catch.

In short, the problem I am trying to solve is to avoid the third party DLL/plugin to crash my program. For now, I can catch the exception from their code as unhandled exception but I don't know how to resume from this exception. I think if I can terminate the thread that cause the exception and resume to the message loop, the program may be able to work again.

Regards

Jeff

[Gabriel Fleseriu]

Question: are we talkig about a C++ exception, or about a SE?

Basically, the rule of COM is that no C++ exception should "bleed" across method calls. If this is your case, and a C++ exception bleeds from the third party DLL into the third party COM component, then you're doomed.

OTOH, resuming after an unhalted SE also is nonsensical, even if you kill the thread that caused it. The reason is, that it will leave you applicaction in an unconsistent state. Killing threads is a last resort idea, generally a bad one.

Of course, what I'm saying is very generally -- I'd need a more detailed knowledge of your code to give a consistent advice. Are you able to write a simple program taht reproduces the error?

[Marco F]

I also don't know what you are doing exactly there, but if the DLL throws C++-exceptions from deep inside the code from an independand thread (and not while you are doing a method call into the DLL) then there are two possibilities:

1) You did something wrong when initializing this DLL

2) This DLL is an instable piece of Sh#*t, you should throw it away or get a bugfixed release from the 3rd party developer.

But the best idea would be to discuss this with the 3rd party developer.

[Igor Vartanov]

Originally posted by jeffchen
Maybe I did not make it very clear. The DLL and the COM component used in my program is developed by third party companies and I can not put a try catch into their code for sure.

No, you've made it clear and I get the problem. And I didn't told you put the try-cach into (see my message - "place a dll function calls in try-catch or __try-__except braces"). It should be the first thing to be tried

try
{
    p3dPartInterface->CallThatBuggyServer();
}
catch( _com_error e )
{
    . . .
}

A similar example may be the plugins for Internet explorer, such as third party toolbar, BHO etc. They have their own message loop/thread and may throw exception from somewhere that my program can not catch.

The code of this sort should catch all its exceptions by itself. If it's not so this code could not be used in commercial projects (as Marco F said). You might set a topmost handler for unexpected exceptions to make your app pretending be stable but to retrieve some useful information you have to do all your best.

In short, the problem I am trying to solve is to avoid the third party DLL/plugin to crash my program. For now, I can catch the exception from their code as unhandled exception but I don't know how to resume from this exception.

Me too. If you kill such thread you leave a bunch of visual controls without correspondent handlers and procedures. I think the only way is to release COM-object (and maybe forget it )

I think if I can terminate the thread that cause the exception and resume to the message loop, the program may be able to work again.

Maybe. And maybe not. Follow the Marco F advice and refer to developer of component.