Why doesn't my program throw exceptions from null pointer dereferencing?

Question

Can someone explain why this exception is not caught.

try { // This will cause an exception char *p = 0; char x = 0; *p = x; } catch (...) { int a = 0; } 

When I run the program, it dies on the line * p = x. I would expect the catch block to ignore this exception.

I am using Qt Creator (2.2) with compiling Qt 4.7.2 with Visual Studios 2008 on 32-bit version of Windows 7.

Answer 1

Handling structured exceptions __try and __catch will catch system errors, see

http://msdn.microsoft.com/en-us/library/swezty51(v=vs.80).aspx

Answer 2

There is no C ++ exception here. You invoke undefined behavior because *p = x derefences a pointer with a null pointer value.

An exception is thrown only when you or the code you call executes the throw statement. undefined behavior usually cannot be catch .

Answer 3

NULL pointer dereferencing is undefined behavior. In general, this will cause a processor trap and an OS level error. This can then be mapped to a signal, such as SIGSEGV , or to an access violation error, or it can interrupt your program or do something else.

On Windows, it maps to a "structured exception", which is another beast for C ++ exception. Depending on how you configured MSVC, you can catch this with catch(...) , but not always.

Answer 4

If you want you to write a test pointer:

 template<typename T> inline T* ptr_test(T* test) { if (test == NULL) { throw std::runtime_error("Null Exceception"); } return test; } 

Then your code looks like this:

 try { // This will cause an exception char* p = 0; char x = 0; *ptr_test(p) = x; // This is what java does. // Fortunately C++ assumes you are smart enough to use pointers correctly. // Thus I do not need to pay for this test. // // But if you want to pay for the test please feel free. } catch (...) { int a = 0; } 

Answer 5

He is not caught, because this is not an exception - he does not throw anything. You gain access to zero / unallocated memory, which causes a segmentation error, which is a signal from the operating system itself.

Signals can only be detected by signal handlers; exceptions will not help you with them.

Exceptions really help in areas where something might throw (), like a library throwing an exception when you call division by zero with the parameters you provided to it.

Answer 6

All you do now is dereference a null pointer, this is no exception.

If you want this code to catch something, you need to quit something first. Say something like:

 try { // This will cause an exception char *p = 0; char x = 0; if (p == 0) throw 1; *p = x; } catch (...) { int a = 0; } 

Obviously, the catch in the above example will always be executed.

Answer 7

You need to use the /EHa to enable (the Microsoft specific compiler), which will allow SEH ( Structured Exception Handling ) exceptions (this is what zero-access triggers) to be a captivating catch(...) .

Having said that, I would not recommend using /EHa . It is better to use the __try/__except extension or the SEH API directly and keep the handling of "structured" exceptions separate from the C ++ exception handling. What for? Since C ++ exceptions is another perfectly legitimate, well-defined flow control mechanism, but most of the things that cause SEH exceptions will most likely indicate that your software has entered the scope of undefined behavior, and in fact the only reasonable thing is come out gracefully. Using / EHa causes this significant difference to become too blurry.