Archived

This topic is now archived and is closed to further replies.

Crispy

handling fatal exceptions

Recommended Posts

I'm not an experienced user of try/catch. I'd like to catch fatal errors, though (such as "memory could not be "read""). For instance, why won't the following work?
      
class B* a = NULL;

try
{
  a->CrashSystem(); //a is not allocated

}
catch(exception& e)
{
  MB(e.what()); //throw a message box

}
The catch block is never reached since the program terminates when I access a in the try block. [edited by - crispy on August 11, 2003 8:45:59 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
C++ won''t catch all these low-level errors. And trying to catch "exception" and expecting to catch all exceptions with it is generally wrong too, since in C++ exceptions don''t have to (and generally don''t) derive from any base class. You should do

try {
//do something evil
} catch (...) {
//error caught
}

catch(...) will catch all exceptions. With this you can try out which errors are thrown as exceptions and which are not.

Share this post


Link to post
Share on other sites
It won''t work. Accessing a null pointer causes the OS to terminate the process and the catch block isn''t executed... From your post I understand that isn''t a valid thrown exception, but I''d still like to handle it my way (eg intercept it before the process terminates). I''m presuming all process information (including the program contents) are available for access, allowing me to output a log or something at this time. To give an idea what I have in mind: ever seen Unreal or BSPlayer crash? They produce and extended window pinpointing the point of termination in code rather than memory.

Share this post


Link to post
Share on other sites
Actually, the specific point that the system will crash is when that member function of class B tries to access any data members of the class.

Calling a method on a NULL pointer isn''t really invalid, since it just means that that NULL pointer gets passed to the function as the ''this'' pointer.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by daerid
Actually, the specific point that the system will crash is when that member function of class B tries to access any data members of the class.

Calling a method on a NULL pointer isn''t really invalid, since it just means that that NULL pointer gets passed to the function as the ''this'' pointer.
I think it''s undefined what happens when calling method on a null pointer. But as far as most implementations go, you''re correct.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
With VC++ you need to enable asynchronous exception handling while compiling (/EHa) and use _set_se_translator() to set your own function that throws a C++ execption when you get Win32 exception. The MSDN docs for _set_se_translator is pretty good.

That said, I would strongly recommend that you DO NOT catch access violations and similar exceptions. These are bugs in your code, and it''s better to let Dr Watson generate a crash dump. Once you have generated an access violation, there''s a significant risk that you''ve blown some of your process memory and it will not work properly. Therefore it''s better to crash to have the problem investigated. By catching them you risk to hide bugs and make them harder to find.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

extern "C" void MyFunc( unsigned int u, EXCEPTION_POINTERS* pExp )
{
throw runtime_error("Sorry...");
}

//at the begin of your code

_set_se_translator( MyFunc );



this help you to catch the c exception and trasform it in c++ std exception.
enjoy.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
_set_se_translator()


Is that like VC-specific because neither Borland C++ 5.02 nor 5.5 header files include anything remotely that? The header file eh.h doesn''t even exist.

Share this post


Link to post
Share on other sites