Re: [basic-improvements] try/finally support for c/c++ - more tests

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov  7, 2002, Aldy Hernandez <aldyh@redhat.com> wrote:

>> But I would like the support for exception handling to include support
>> for throwing and catching exceptions, not just try/finally.  The current
>> proposal seems too limited to be useful for much else than glibc, IMHO.

> How are you going to handle catching exceptions, given that we have no
> way to recognize certain types in C (templates, classes, etc)?

You don't recognize types.  You just catch everything.  Which sounds
perfectly reasonable from a C standpoint.

One of the things I liked about the C front-end of GCC was that it
could pretty much exercise any of the features available to all other
languages: nested functions, so that you could do the same as Pascal;
extended inline assembly, such that you didn't have to fallback to
assembly for everything; variable-sized types, like some other
languages support; expression statements, etc, etc.  The nice thing
was that C could really be used as a high-level assembly, exercising
most (if not all) of the internal features the back-end would have to
implement for other languages anyway.

This broke down when Ada and C++ introduced exceptions as
language-specific extensions, and then, even though C++ exceptions
were later integrated into the generic back end framework, they were
still unavailable in C.

I personally think cleanups are a step in the right direction of
restoring the ability to exercise all features of the compiler in a
single front end.  I don't really care if it's C, C++, treelang or
something else, but clearly to me C++ is not a good candidate since it
fails to support a number of other gcc extensions that the C front end
supports.

So I'm all for bringing back-end-supported exception handling support
features into our higher-level assembly.  I wouldn't go as far as
supporting catches and throws right now, given that we don't have a
clean design for this feature, but try/finally looks terrifically
simple, and it's not like it's a new idea: as many others have pointed
out, other compilers already support it, so it's likely to gain
acceptance in the next round of C standardization.  Even more so if we
choose to support it exactly like other compilers do.

The other advantage I see in offering not only clean-ups, but actual
exception catching and throwing in our high-level assembly, is that we
can then write glue code to convert exceptions from one language to
another.  Currently, there's really no simple way to do it, to the
best of my knowledge.  I'm not saying writing such glue code would be
simple, but at least someone wouldn't have to write such glue as a
number of functions that call one-another, each one implemented in a
separate exception-supporting language.  Being able to unify the EH
framework and expose it to the user would even enable us to implement
EH supporting routines for languages in our higher-level assembly.

But then, again, for actual exception handling, we still need more
discussion and design, but for clean ups, there's really not much
possibility for variation in the design and syntax, and following
existing practice in other compilers and languages is clearly a plus.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer