Identifying Exceptions in catch(...)

>>catch(...)

If you are indeed referring to the 'catch()' handler with the ellipsis - no. That's not possible since you don't have any kind of type information about the exception being caught.  It could be anything from a 'std::exception*' to a plain char* or even an integer. What OS are you on?

If you're compiling MFC code, you could use TRY-CATCH with CException which will give you more info.

What type of project are you compiling, and what's your compiler and OS?

Hi

This is Windows 2000.
That's the problem - I don't have a clue what's being thrown.  

The code is like this...


try {
    foo(c);
}
catch (...) {
  cout << "error" << endl;
}

I've try..catched every single line executed inside foo, without catching any errors - and get an error after returning from the function call - out of the blue it seems.
Driving my nuts.

Best regards,
bragn.

vc++
running in console mode.

>>I don't have a clue what's being thrown.  

When you run it under the VC++ debugger, you'll see what exception is being thrown - at least, if it is SEH related ('catch()' will e.g. not 'see' access violations). BTW, the following filter will help you to track these OS related exceptions which are not related to C++ exceptions:

LONG
WINAPI
MyExceptFilter ( LPEXCEPTION_POINTERS pe) {

      TRACE1 ( "Caught SEH Exception 0x%8.8x\n", pe->ExceptionRecord->ExceptionCode);

      return EXCEPTION_EXECUTE_HANDLER;
}

SetUnhandledExceptionFilter ( MyExceptFilter);

You can try using __try __except type code.

Hi jkr.

It's a bit difficult for me to run in VC++ debugger - rather impossible.
How can I use this filter?  Can you show me how I apply this in action?  Not my strongest territory....

Best regards,
bragn

May be you can use SEH(System Exception Handling)

Here's example code from a previous post:

void  LockDebug   ()
{
    __try   //  setup SEH frame - this frame will 'see' (handle)
            //  the EXCEPTION_BREAKPOINT if no debugger is present
    {
        //  issue an 'EXCEPTION_BREAKPOINT' - when  no debugger is
        //  present, our SEH handler will be executed...

        DebugBreak  ();

        //  if we reach this point, a debugger is attached to
        //  this application (and someone decided not to give up ;-)

        OutputDebugString   (   "Don't debug me!!!\n");

#ifndef __HARD_AND_MEAN_EXIT
        ExitProcess (   0);
#else
        TerminateProcess    (   GetCurrentProcess   (),
                                0xffffffff
                            );
#endif
    }
    __except    (       EXCEPTION_BREAKPOINT    ==  GetExceptionCode    ()
                    ?   EXCEPTION_EXECUTE_HANDLER
                    :   EXCEPTION_CONTINUE_SEARCH
                )   //  just to make sure we're not handling sth. else...
    {
        //  Fine! This was our 'DebugBreak()', all's well, do nothing
    }
}

>> May be you can use SEH(System Exception Handling)

'Structured Exception Handling' - and I have a blurry memory that I already read about that in this thread :o)

>>How can I use this filter?

Add the code to your application and call 'SetUnhandledExceptionFilter ( MyExceptFilter);' in your 'main()' function

Here's a simple version:
    __try {
        //Do code here that raises exception
    }
    __except ( 1) {
        printf("Caught EXCEPTION %i \n", GetExceptionCode());
    }

This really was looking good., until....

error C2712: Cannot use __try in functions that require object unwinding

Any comments on that?

Best regards,
bragn

Well

I almost by "accident" commented out the faulty code.
The error seems to be thrown when trying to release an ado connection.

I'll look better into what you guys posted and use later I'm sure.

Splitting the points between jkr and Axter.

Learned more in 15 minutes than all day ....

Best regards,
bragn.

>> It's a bit difficult for me to run in VC++ debugger - rather impossible

What is the problem?

(A) doesn't it compile in Debug Mode or
(B) can't you start it from Visual Studio or
(C) was it invoked by another process or
(D) is it a service?

If (A) you should tell us the issue
If (B) or (C) you could attach an empty Visual Studio to a running process by

      Build - Start Debug - Attach to Process ...

If (D) you should add the capabilty to run the service as a console program, e. g. by handling -d
commandline argument and calling service_main directly from main()

The advantage of having the program run in Debug Mode is, that you can see any exception thrown in the Output window - as jkr already told you. Furthermore, If you know the type of the exception you may force the Debugger to stop the program when ts thrown, what may give you the reason why it happens at all.

Regards, Alex