From: Jeremy Day (jeremy.day_at_[hidden])
Date: 2006-07-28 08:31:23
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