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

Zack Weinberg
Tue Feb 1 13:13:00 GMT 2000

On Tue, Feb 01, 2000 at 12:49:01PM -0800, Bill Tutt wrote:
> On Tue, 1 Feb 2000, Bill Tutt wrote:
> > Which looks frightfully silly to me. If you're only talking about
> > synchrnous exception handling, I still don't see why C would need a
> > try/catch syntax since it doesn't have any useful understanding of the
> > exception state at all. 
> Unless of course you do want to give C some understanding of the C++
> exception state, which I haven't seen anyone even come close to
> suggesting.

I believe that is exactly what people want.  To be more specific,
system libraries written in C need to be able to generate exceptions
in a C++ compatible fashion, and cope with exceptions thrown through
them from callbacks.  The pthreads library is the obvious example
since it has a pseudo- exception facility built in

Given that, it makes most sense to make the C syntax and semantics be
as close to C++ as possible.  We can't import the C++ model wholesale
because it depends on RTTI and objects, but I think that

  __try {
     /* code */
  } __catch {
     /* clean up */
  /* maybe clean up here too */

invents fewer new concepts than adding a __finally.  Also note that
pthread_cleanup_pop() does not always execute the cleanup function you
registered earlier.

Another thing to think about - it'd be Nice if setjmp/longjmp
interoperated with throw/catch, partially because that would make the
behavior politer to C++ code, partially because the compiler would
comprehend control flow better.  (On second thought, there may be code
out there that expects that longjmp() will go directly to its target,
not visiting catch handlers and not collecting $200.)


More information about the Gcc mailing list