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@lists.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.