Minor exception bug with unexpected
ak@muc.de
ak@muc.de
Thu Mar 19 22:11:00 GMT 1998
On Fri, Mar 20, 1998 at 06:12:39AM +0100, Alexandre Oliva wrote:
> ak writes:
>
> > On Thu, Mar 19, 1998 at 04:24:35PM +0100, Alexandre Oliva wrote:
> >> ak writes:
> >>
> >> > The appended example dumps core in __check_eh_spec. Although that
> >> > is legal in CD2 [except.special says "The unexpected() function shall
> >> > not return"], it is still not very nice to the user. The patch
> >> > makes unexpected() call terminate() in this case.
> >>
> >> I'd rather call abort() instead of terminate(). Calling terminate()
> >> might cause yet more unexpected results (unavoidable pun, sorry :-)
>
> > What unexpected results should it cause? abort is a bit too radical
> > for my tastes.
>
> What if terminate() is replaced by the programmer too, and it returns
> instead of calling terminating? Instead of adding a call to
> terminate() then a call to abort(), I'd rather call abort() directly,
> because terminate() is *not* expected to be called after unexpected().
> Since we're moving into grey area (undefined behavior), I'd rather
> keep things simple, and abort()ing seems better to me, even for
> debugging purposes.
You're right. I didn't notice that __default_terminate() calls abort()
instead of a cleaner exit(0). My prefered behaviour would be
/* Or the equivalent on the non-unix gcc target, otherwise nothing */
write(1, "unexpected exception\n", 21);
exit(1);
abort() usually causes a core dump which I see as overkill here.
Comments?
-Andi
More information about the Gcc-bugs
mailing list