[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

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