Boost logo

Boost :

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

thanks a lot for your comments.

Stewart, Robert wrote:
> 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


> 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? :-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at