$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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:
> http://www.mail-archive.com/boost@listarchives.boost.org/msg05179.html
Thanks for the link, it shows that there's an interest in something like
that.
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
whatsoever.
Thanks,
Andy.