Re: [boost] Any interest in trap_exceptions functionality?

Subject: Re: [boost] Any interest in trap_exceptions functionality?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-07-30 17:13:16

Andy Venikov wrote:
>
>   I often find myself wanting a generic way to catch and
> process exceptions.
[snip]
>    I recently took a crack at this task and came up with a
> generic way to trap exception.
>
> Here's a brief API:
>
> trap_exceptions(<list-of-exception-handlers>);

The idea is interesting, but I see issues of general applicability.  For example, there are relatively few circumstances in which one needs to do much of that sort of exception handling.  I don't mean to suggest that it doesn't occur, but I wonder if it occurs often enough to warrant a Boost tool.  Another issue is that your approach eliminates access to the calling context.  Any handler that needs such access becomes much more complicated.  That by no means is required in all circumstances, but it is an issue to consider.

Both of those issues can be addressed by a straightforward, ad hoc macro approach.  The common handlers can be assembled in a macro invoked in each function needing them.  The preprocessor then inserts the code.

Is there enough value in your idea to justify a Boost library?  Perhaps you'll overcome these issues and prove the value.  For example, if trap_exceptions() accepted lambdas, then the calling context would be accessible, at least in C++0x.  (Phoenix 3?)

As to the general problem you're solving, my solution has always been this:

extern "C"
void
f()
{
   try
   {
      // do possibly throwing work here
   }
   catch (...)
   {
      handle_exception();
   }
}

where handle_exception() looks like this;

void
handle_exception()
{
   try
   {
      throw;
   }
   catch (first_type const & e)
   {
      // deal with first_type exception
   }
   catch (second_type const & e)
   {
      // deal with second_type exception
   }
   ...
   catch (...)
   {
      // deal with unrecognized exception
   }
}

That also suffers from the lack of calling context, but does otherwise serve to fulfill the same need as your solution, except that it isn't composed via function pointer arguments.

I have also generalized that scheme in some cases to permit a caller to install a handler function.  Thus, in the catch all handler, if a handler function has been installed, I call that to give a last chance to decode and handle the pending exception.  That means some types are always handled the same way.  The other approach is to have a function like handle_exception() be the default and allow the user to install a replacement function.

I've even created a framework whereby the type and message of various exception types can be normalized for logging or translation, including the ability to extend the supported types through virtual functions.

The point is there's a lot of room for providing help with exception handling for various purposes, but I'm not certain whether your approach is broadly useful.  I'm open to being convinced, however.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.