handling fatal exceptions

Started by
8 comments, last by Crispy 20 years, 8 months ago
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]
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared
Advertisement
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.
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.
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared
Did you try looking up stuff on Win32 SEH? That would probably catch them.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
I''m reading the Deep C++ series right now. Quick browing says it goes over this stuff in later chapters. I''ve never paid too much attention to exception handling anyway, so it''s a fun read.
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared
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.
daerid@gmail.com
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.
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.
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.
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.

"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared

This topic is closed to new replies.

Advertisement