Structured Exception Handleing

Started by
2 comments, last by KulSeran 15 years, 9 months ago
Ok, so i found this wonderful trick MS lets you do in their compiler.

LogSystemStart();
Log() << "App Start" << Log::endl;

u32 rVal = 0;
__try
{
  rVal = Game_Main(argc, argv);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
  rVal = -1;
}

Log() << "App End" << Log::endl;
LogSystemStop();
//cin.get();

And then viola! my logger thread will now finish running even if Game_Main crashes for some reson. So, no-matter what, I can get formatted data out of my logger without worry of losing messages due to it being buffered at the moment of a crash. BUT, for some reason this feels really hacky. Is there a way to do this on platforms other than windows (i know __try is MS only) and even if there isn't, is this still the right way to program for this sort of situation?
Advertisement
Well, linux allows you to set signal traps, you can catch segmentation faults with that.

But overall, catching access violations or segmentation faults or whatever is non-portable, simply because C++ doesn't deal with such cases. It's in the realm of undefined behavior. You can't do a whole lot, either. If you get an AV your whole program could be messed up. Typically, developers just dump a strack trace with advanced error information to a file and bail out 'gracefully'.
Million-to-one chances occur nine times out of ten!
Quote:Original post by Mike nl
Well, linux allows you to set signal traps, you can catch segmentation faults with that.

The language itself has several signals you can catch, which are inherited from C. Linux (and most other UNIX and UNIX-like systems) use that mechanism.

The C-required signals are SIGABRT (abnormal termination, initiated by OS or abort function), SIGFPE (math error like divide by zero or certain math overflows), SIGILL (invalid function image, such as invalid instruction), SIGINT (general interactive attention signal) SIGSEGV (invalid access, segmentation fault), and SIGTERM (termination request signal).

If you need a general handler for unhandled C++ exceptions, you can register a function with set_unexpected(). There isn't much you can do at this point other than quit, but it is very useful for collecting crash information.

You can also register any number of exit functions with atexit() that will be called in reverse order on a normal exit. Your application may or may not call these when exiting by abnormal paths.
Ok, so the signal thing seems like it will work just fine (and seems less tied to the platform than the __try blocks)

This topic is closed to new replies.

Advertisement