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

llewelly@198.dsl.xmission.com llewelly@198.dsl.xmission.com
Tue Feb 1 13:33:00 GMT 2000


On Tue, 1 Feb 2000, Zack Weinberg wrote:

> 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
> (pthread_cleanup_push).

Currently, you can compile C code with -fexceptions, and throw C++
  exceptions across the resulting functions. I have found this to very
  useful, even necessary at times. 

If system libraries (written in C) generate exceptions. I would like to be
  able catch them in C++ code, preferably with the standard C++ exception
  syntax and semantics. More importantly, I want C++ destructors to be
  called when the stack is unwound.

So yes, what you are talking about is what I want most.

> 
> 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 */

Perhaps I shouldn't open my mouth and stick my foot in it again, but
  aren't you missing a '__throw;' here, so the cleanup code will get
  called even if an exception is thrown? That way you don't need two sets
  of cleanup code. (of course, there is the performance penaly of the
  __throw;)

>   } __catch {
>      /* clean up */
>      __throw;
>   }
>   /* 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.)
> 
> zw
> 




More information about the Gcc mailing list