[boost] Re: guidelines on portable 'catch(...)' usage

From: Ken Hagan (K.Hagan_at_[hidden])
Date: 2004-10-28 04:29:23

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.