Stefan Seefeld wrote:
hi there,
I'v recently run into a problem with 'catch(...)' on MSVC 7.1, where a segmentation fault resulted in a 'first-class exception' (!) that was caught by 'catch(...)' even though the stack wasn't unwound.
(Nit: Are you sure it wasn't "first chance" exception.) I don't think it is possible to provoke a seg fault without attempting an illegal pointer dereference. (Guard page faults for growing the stack are handled transparently by the kernel.) Therefore, I'm inclined to think that "So don't do that." is the appropriate (if unsympathetic) response.
My first reaction was to abandon the use of 'catch(...)' entirely, replacing it with a more specific equivalent (which I believe to be better practice anyways).
However, browsing some boost code I now find other people using such catch-all statements, and so I'd like to get your feedback on how to use it portably.
If your code is portable, then catch (...) is the only way to deal with the fact that not everything is derived from std::exception. I see nothing wrong with it.
Are my findings false concerning MSVC's highjacked use of C++ exceptions for program errors (i.e. POSIX' equivalent of signals) ?
MSVC's implementation of POSIX signals may well be incompatible with their implementation of catch(...). Come to that, it is probably incompatible with Win32's SEH. Er, so that would be just plain broken then? That tells you how much MS care about POSIX signals. However, avoiding catch(...) strikes me as quite a considerable loss, whereas avoiding POSIX signals in Win32 software (the only thing that MSVC targets) strikes me as hardly any loss at all. If we are considering portable code, we are only considering manually raised signals. They must be almost unheard of in C++ code and fairly uncommon even in the C code that we (nearly) all have to work with.