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