This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]