------- Comment #66 from hhinnant at apple dot com 2008-11-20 17:40 -------
(In reply to comment #65)
> Subject: Re: exception_defines.h #defines try/catch
>
> No, it doesn't make any sense to use try/catch in a program that you're
> planning to build with -fno-exceptions. It does, however, make sense to
> use try/catch in a general purpose library that you want to work with
> exceptions enabled or disabled, such as libstdc++.
>
> I believe Lubos is arguing that such libraries ought to use preprocessor
> tricks to accomplish this, but defining something like __try and __catch
> instead of try and catch. The difference between this approach and my
> patch is that it requires the library writer to jump through hoops to
> make their code work with exceptions enabled and disabled. I guess
> Lubos thinks this is good, that this is an unusual thing to want to do
> and so people that want to do it need to be very explicit about it so
> that people who don't want that but mistakenly build their code with
> -fno-exceptions get an error rather than a warning.
>
> Anyone else have an opinion about this?
>
> And yes, -Wexceptions is on by default in my patch.
I've tried really hard to just stay out of this one. :-) I think Jason makes a
good argument. However I just surveyed a bunch of my own code written to work
both with and without exceptions enabled, using "macro hoops". In about 95% of
the cases transforming:
try
{
X
}
catch (Y)
{
Z
}
to just:
X
is exactly what I want. In the other 5% of the cases it is not. In these
(relatively rare, but not uncommon) cases, the code under X gets transformed
into code that checks return values for error codes and acts on that error
code:
int er = X
if (er)
return P
This scenario usually pops up when X is doing an allocation which throws when
exceptions are enabled and returns null when exceptions are disabled.
All that being said, is Jason's patch good or bad? <shrug> I'm still going to
have to manually design 100% of my try/catch clauses for exceptions enabled and
disabled. If I don't, then I'll have a 5% bug rate even with Jason's patch.
Part of me would prefer the error just to ensure that I haven't forgotten to
design for the exceptions-disabled case, even if that design would simply
translate to X. Perhaps the warning will fill that role, I do not know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
