From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-08-08 10:56:12
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
} 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
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 ;-)
PS: what about BOOST_DEFINE_EXCEPTION_HANDLER stuff? do you need a help
Jeremy Day wrote:
> On 7/28/06, Ames Andreas <Andreas.Ames_at_[hidden]> 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'.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk