Boost logo

Boost :

Subject: Re: [boost] Any interest in trap_exceptions functionality?
From: Andy Venikov (avenikov_at_[hidden])
Date: 2010-08-02 12:36:12

David Abrahams wrote:
> At Fri, 30 Jul 2010 16:21:13 -0400,
> Andy Venikov wrote:
>> 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>);
> I think there's something like this in Boost.Python, and, IIUC, in
> Boost.Test as well. Ah, yes. I suggest you review this thread:

Thanks for the link, it shows that there's an interest in something like

If I understand that thread correctly, boost.Python provides a way to
dynamically register exception translators (which for all intents and
purposes are just handlers)for different types of exceptions.

While I think that it's somewhat similar to trap_exceptions, the
purposes are very different. Boost.Python.exception_transator is totally
dynamic, hence the need to use virtual functions and "new". You also
have to use the "register" mechanism to register all your handlers
individually. I understand that this approach is a must where you may
have dynamic components like in Boost.Python and Boos.Test, but when you
are simply trying to re-factor your code so that the resulting binary is
the same, but the source is organized better, I think a static approach
is more fitting. If I didn't have a requirement to support function
pointers, then the result of trap_exceptions could've been just a type:

trap_exceptions<...list of exception handling functor types...>::type

Even with function pointers, their type and their number is known and
queriable (they are stored in a tuple<>). The only indirection here is
the function call itself. When functors are used, there's no indirection


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