Regarding Exception handling

[Paul McKenzie]

Here is an example from you,

void foo()
{
   try
   {
        char *p = 0;
        *p = 'x';.
   }
   catch(...)
   {
          // 
   }
}

int main()
{
   try
   {
      foo();
   }
   catch (...)
   {
   }  
}

In the try block of function foo, no throw is thrown. So you think catch never catches any exception?

See the first reason for a catch to be invoked. I don't know what the inner workings of the C++ SEH switch are, but there is no doubt -- the internal code is issuing a throw.

Again, there are only three reasons why catch() becomes invoked. No other reasons exist.

A lot of programmers believe that the catch() works by magic, and anything wrong with your program falls into the catch. Nothing can be further from the truth -- only thrown exceptions will wind up in catch blocks. Whether all SE's issues a throw, that I don't know. I showed you the code to handle the exception yourself using a handler, and then you throw from there, guaranteeing that your catch() will be invoked.

Regards,

Paul McKenzie

[LarryChen]

See the first reason for a catch to be invoked. I don't know what the inner workings of the C++ SEH switch are, but there is no doubt -- the internal code is issuing a throw.

Again, there are only three reasons why catch() becomes invoked. No other reasons exist.

A lot of programmers believe that the catch() works by magic, and anything wrong with your program falls into the catch. Nothing can be further from the truth -- only thrown exceptions will wind up in catch blocks. Whether all SE's issues a throw, that I don't know. I showed you the code to handle the exception yourself using a handler, and then you throw from there, guaranteeing that your catch() will be invoked.

Regards,

Paul McKenzie

I thought there is two kinds of exceptions. One is simply C++ exception and another one is hardware exception issued by OS such as access violation exception. In your example,

void foo()
{
   try
   {
        char *p = 0;
        *p = 'x';.
   }
   catch(...)
   {
          // 
   }
}

int main()
{
   try
   {
      foo();
   }
   catch (...)
   {
   }  
}

Obviously this is an access violation exception. So I assume it is issued by OS. Basically first question I have is that in the example above, is it ALWAYS successful to catch this access violation exception since catch block above expects a C++ exception. In order to catch an access violation exception, we must convert the exception above into a C++ exception. Then catch block can always catch such exception. Any comments are welcome! Thanks.

[Paul McKenzie]

I thought there is two kinds of exceptions.

In C++ there is only one kind of exception, and that is the one defined in the ANSI/ISO specification.

Obviously this is an access violation exception. So I assume it is issued by OS. Basically first question I have is that in the example above, is it ALWAYS successful to catch this access violation exception since catch block above expects a C++ exception.

Again, something has to throw for a C++ catch to be invoked. The runtime probably issues a throw for this particular issue.

In order to catch an access violation exception, we must convert the exception above into a C++ exception.

And then you throw this C++ exception yourself.

You always, for some reason, miss this step in your analysis. I've said this at least three times now, and also gave you to a link to the code that shows this to you. The code uses something similar to an error callback function , and within that callback, a throw is explicitly done.

The bottom line is this -- there is nothing in C++ itself that handles OS exceptions, nothing. All of that work is done by the compiler libraries. If you were to go to another compiler, there is no guarantee that the compiler would catch an access violation or whatever other OS exception that can be generated.

What does work is to set the se_handler, and have it throw a bonafide C++ exception back to the application. This is guaranteed to work because your code will be explicitly doing the throw.

Look at it this way -- I give you a library that has no exception handling whatsoever, and you don't have the source code to the library. All I do give you in terms of error handling is a function that the library calls when something goes wrong (similar to the se_handler function). I allow you to hook this error function and replace it with yours using a regular 'C' callback function. How do you set up your app to make it catch C++ exceptions, and have it reliably catch all the errors my library reports? Remember, my library has no exception handling whatsoever.

If you can't answer or know how to do that, then you won't be able to solve your issue.

Regards,

Paul McKenzie

[LarryChen]

None of this works if something doesn't throw. You can do all the try/catch in the world, if nothing does a throw, you aren't going to catch anything,

The way that try/catch works is simple -- something must throw first. The throw is part and parcel of this whole scheme, and you're leaving out this important step.

If anything, the se_handler gets invoked by the OS, then you're responsible to put together an exception object in your C++ code, and you throw your exception object.

void your_se_exception_handler( whatever )
{
     // create your own exception object derived from std::exception
     MySEException se;
     //....
     throw se;
}
//...
try 
{
    int *p;
   *p = 0;
}
catch( MySEExceptioin& se )
{
}

In the example you gave earlier, your_se_exception_handler is defined but it is never called. How should I use this function in the following try/catch blocks? Thanks.

[Paul McKenzie]

In the example you gave earlier, your_se_exception_handler is defined but it is never called. How should I use this function in the following try/catch blocks? Thanks.

That is because it is a callback function. The OS calls that function when an SE occurs. You don't call it.

Again, read the link I gave you. There is a full example below.

Regards,

Paul McKenzie

[LarryChen]

That is because it is a callback function. The OS calls that function when an SE occurs. You don't call it.

Again, read the link I gave you. There is a full example below.

Regards,

Paul McKenzie

Thanks so much for your explanations. Now I think I understand this approach. I have one more question. Why'd we still need __try/__finally in order to generate a c++ exception? What is __try/__finally for? Thanks.

[LarryChen]

I have a question. Since structured exception is asynchronous exception. So I wonder if it is possible that not all the structured exceptions will be caught when we use __try/__finally to handle structured exceptions.

[OReubens]

__try/__except/__finally works different from normal try/catch.

object destruction and stack rollback aren't going to work similarly.