Hello Jeremy! There is a strong opinion against catch(...) clause. But problems, mentioned by Alexander Nasonov and Ames Andreas could be worked around. 1) define a BOOST_BROKEN_CATCH_ALL configuration macro that is non-zero when compiling in mode where catch(...) is dangerous (BOOST_MSVC is defined and _MSC_VER is in a predefined range. according to Peter Dimov MSVC 8 doesn't catch SEH exceptions with ... by default) 2) protect all code in your catcher.hpp with this macro and place #error message in #else branch that describes the problem with catch(...) on a given platform. Later it can be replaced with macroses, proposed by Alexander Nasonov: try { throw std::logic_error("testing"); } BOOST_CATCH_PP_SEQ((ex1)(ex2)(ex3), my_exception_handler()); alternatively or additionally, you can provide here an implementation that catches not for ... but for std::exception& It completely eliminates the original problem but restricts user to only std::exception - derived exceptions. to extend this approach a bit you can provide user a possibility to define BOOST_EXCEPTION_BASE_1, BOOST_EXCEPTION_BASE_2, etc up to predefined limit. and use these macros to catch (BOOST_EXCEPTION_BASE_N) for all N defined by user. Alexander? Ames? What do you prefer here? 3) write a test case for the macro defined in (1). it should contain code that generates SEH and tries to catch it with catch(...). if it succeed - test fails, else - passes. finally, protect this code with the macro defined in (1), so if the macro defined correctly, test code expands to nothing on problematic platforms, else expands to all test code. But I'm not sure if and how it can be implemented on all platforms, though. As a first step you can provide a very simple definition for BOOST_BROKEN_CATCH_ALL macros and protect your catcher code with it (+ #error message) and let interested people do the rest ;-) Best, Oleg Abrosimov. PS: what about BOOST_DEFINE_EXCEPTION_HANDLER stuff? do you need a help with it? Jeremy Day wrote:
On 7/28/06, Ames Andreas <Andreas.Ames@comergo.com> wrote:
FWIW, I'd like to strongly second that. When catching SEH exceptions (like catch(...) does), predictable behaviour is only possible if you compile for 'asynchronous exception handling', which according to the docs increases the generated code size (I don't know about the runtime performance cost). If you compile for 'synchronous exception handling' (the more usual thing, I believe), you should either be prepared to live with bad cleanup of the stack or you install a global SEH-exception handler in each thread you start, which does nothing but rethrow and therefore crash the app. IMHO, that's nothing a library should impose on its apps. Anyway, I fail to see what's the benefit of catching segfaults _as the default behaviour_ (that's not to say there aren't applications that need to do).
Ah, I think that I have been misunderstood. I simply said that I thought that catching SEH exceptions _could_ be a good thing that and that I would _like_ for all exceptions to be caught. I don't have any particular interest (or, more importantly, time) in implementing something like that and foisting it upon people. I'm reasonably happy with BOOST_CATCH as it exists right now, so I'm going to explore ways to make it easier for users or more efficient. I am not going to force users into some sort of exception handling choice that they don't want.
Keep the comments comin'.
Jeremy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost