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

[Daniel Jacobowitz]

On Thu, Nov 07, 2002 at 05:55:21PM -0800, Mark Mitchell wrote:
> 
> 
> --On Thursday, November 07, 2002 08:52:37 PM -0500 Jason Merrill 
> <jason@redhat.com> wrote:
> 
> >On Thu, 07 Nov 2002 17:26:38 -0800, Mark Mitchell <mark@codesourcery.com>
> >wrote:
> >
> >>>That's why the proposal is about __try/__finally only, not __except
> >>>where it is e.g. not clear at all what happens if you throw in C++
> >>>and __except control expression returns -1.
> >>>At least from what I read in MSFT docs on the web, their __try/__finally
> >>>matches Aldy's patch.
> >>
> >>Except that it also handles asynchronous exceptions, which ours doesn't.
> >>Where we'd get a SIGFPE you get a structured exception in Microsoft's
> >>stuff.
> >
> >That has nothing to do with the semantics of try/finally, which just deals
> >with cleaning up after whatever exceptions do happen to be thrown.
> 
> This horse is pretty dang dead, but the point is that people will *expect*
> that the construct behaves the same way as Microsoft's "structured
> exception handling" stuff -- in every way.  Part of that is handling
> SIGFPE type events.

If you look through the list archives, you'll see that people _already_
expect that; we get a "why doesn't C++ catch{} block catch SIGFPE"
every couple of months.  I don't think this would make it any worse.

And adding platform-specific code to catch SIGFPE's and unwind is not
all that hard.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer