Re: [boost] Runtime error reporting

From: Jesse Jones (jejones_at_[hidden])
Date: 2001-03-20 17:03:32

>Let me suggest the following idiom as a reasonable way to report
>fatal runtime errors:
>
>   template <typename X>
>      void error(const X& x) throw() {
>         throw x;
>      }
>
>Yes, it looks silly.  But it will force a call to unexpected(),
>which by default will terminate(), and the client can replace
>the default behavior via the standard set_unexpected() facility.

How does the handler get at x?

>What the client cannot do is contrive to keep running despite
>the error, so it is not appropriate for those who a prefer a
>"damn the torpedoes, full speed ahead" style of error handling.

In debug, at least, it's really nice if you can continue running even after
you've hit an assert.

What's wrong with a more or less traditional approach? Something along
these lines:
   #if defined(NDEBUG) && !defined(ALWAYS_ASSERT)
       #define ASSERT(p)    ((void) 0)
   #else
       void AssertsAbort(const char* expr, const char* file, int line);
       // write to stderr and abort

       void AssertsBreakToDebugger(const char* expr, const char* file, int
line);
       // drop into the debugger if one is present, if not call AssertsAbort

       void (*gAssertFailed)(const char* expr, const char* file, int line);
       #define ASSERT(p)    (!(p) ? gAssertFailed(#p, __FILE__, __LINE__) :
(void) 0)
   #endif

Other than the ODR problem and the names. :-) Boost might initialize
gAssertFailed to AssertsAbort, but clients could switch to one of the other
provided handlers or they could use a custom handler.

This provides what I want in an assert:
1) The ability to turn asserts off in release and pay no penalty in runtime
or data overhead (eg froms string literals).
2) Having the option of having assert call something like EmergencyShutdown
in release so that I can save the user's data in a special file.
3) Being able to customize the assert so that it does different things in
debug. In particular I want to take advantage of a debugger if one is
present.
4) Having the option of continuing as if nothing happened when an assert
fires. This might be problematic in release, but it sure is handy in debug
builds.

  -- Jesse