This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)
- From: Bill Tutt <rassilon at list dot org>
- Date: Tue, 1 Feb 2000 02:05:59 -0800 (PST)
- cc: Zack Weinberg <zack at wolery dot cumb dot org>, llewelly at 198 dot dsl dot xmission dot com, Bill Tutt <rassilon at list dot org>, gcc at gcc dot gnu dot org
On Tue, 1 Feb 2000, Richard Henderson wrote:
> On Tue, Feb 01, 2000 at 12:26:36AM -0800, Zack Weinberg wrote:
> > The other thing to consider here is we probably don't want to drag all
> > of RTTI into C.
>
> I don't think that's really a problem. Modulo the cancel-exception
> thing, we could model MS EH like
>
> __try { foo(); }
> __except (some-test) { bar(); }
> __except (some-other-test) { baz(); }
> to
> try { foo(); }
> catch (...) {
> if (some-test) bar();
> else if (some-other-test) baz();
> else throw;
> }
>
> Not quite as efficient as triggering off a type, but who ever
> worried about run-time efficiency of exceptions, anyway.
>
MS EH doesn't support multiple __except blocks attached to one try block,
so this isn't a problem.
The annoying thing is that C based try/catch handlers need some kind of
information about the exception that occurred if they want to do any
useful processing. So if the C based try/catch handlers can't catch
asynchrnous exceptions (segv, divdie by zero, etc) and information about
C++ based exceptions is kind of useless is there any reason we need
try/catch for C at all? i.e. can we get away with just a try/finally pair?
This avoids the GetExceptionCode() problem altogether, but leaves
AbnormalTermination(), but that seems like a fairly simple gcc builtin to
code up.
Bill