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