Re: [boost] Any interest in trap_exceptions functionality?

Subject: Re: [boost] Any interest in trap_exceptions functionality?
From: Andy Venikov (avenikov_at_[hidden])
Date: 2010-07-30 19:35:49

First,
thanks a lot for your comments.

Stewart, Robert wrote:
<snip>
>
> 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.
Well, I think it's all relative. I think that this sort of functionality 
is useful at the boundaries of logically separate modules. How often you 
deal with these boundaries depends on what kind of applications you 
usually work with. In my personal experience I think I needed it 4-5 
times. Enough to make me bother trying to generalize it. But you're 
right, I'm sure that there are tons of developers that didn't see a need 
for this kind of exception handling.

>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.
I think that in most cases the local context is not required, unless the 
  exception handling is done in a mother-of-all-functions, in which case 
one could have handlers that are aware of the function's context. (What 
I mean is that if the local context is needed, then the function is 
probably big and one could spend some time writing functors that know 
the function's context). Since the trap_exception syntax is really 
light-weight, it becomes easy to create traps with different set of 
handlers. Also, as you point out further down yourself, a lambda 
function could be used. I think C++0x style lambdas should work jsut 
fine with trap_exceptions since they are not polymorphic. The only 
lambdas that can be problematic are polymorphic lambdas, since in that 
case I won't have access to the type of exception that needs to be 
caught. But I'm sure there should be a way to supply that type elegantly.

> 
> 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.
Yeah, I'm aware of the macro approach. But what you lose with the macro 
approach (not mentioning the fact that you have to deal with them :-) ) 
is the ability to easily create different traps with different sets of 
exception handlers. I'm sure that a macro guru could probably replicate 
trap_exceptions functionality using just macros, but then the solution 
will become probably a lot more complicated. The straight macros won't 
take exception types as argument and you'll end up creating different 
macro for every different set of exceptions.

> 
> 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?)
I didn't think myself that it should be a separate library. Perhaps a 
part of utility? Or another library.

> 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
>    }
> }

Again, it's burdensome to create separate handlers for different sets of 
exceptions and the developers will tend to write one giant 
handle-them-all handler.
Whereas with trap_exceptions you can just compose them in-place.
But I gotta admit that for some reason I really underutilized the 
approach that you just described. It's not that I wasn't aware of it, 
but somehow it just never came to my mind when considering this kind of 
exception handling. Maybe some subconscious aversion to the try/catch 
syntax?

<snip>

> 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.
Well, I hope maybe my reply did the job? :-)

Thanks,
    Andy.