Re: [boost] Exception Visitor

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-08-08 10:56:12

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_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'.
> 
> Jeremy
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>