Re: patch: <bits/localefwd.h> with -fno-exceptions

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

    Jason> Out of curiosity, which compilers have you tried, other
    Jason> than EDG?  Do they also disallow empty throw specs?

HP's aCC.

That's a good question about the throw specs.  I will check...

I don't have access to aCC at the moment -- but Sun's compiler agrees
with you.  Oddly, this incarnation of Sun C++ simply ignores throw
expressions -- but accepts them:

"test.C", line 2: Warning: throw expression ignored when compiling with -noex.
1 Warning(s) detected.

This is more extreme even than your position, relative to mine.

    Jason> The purpose of the flag, from a user perspective, is to
    Jason> avoid the overhead associated with exception handling.

And, perhaps, to claim that the program has no exception-handling
code and to ask the compiler to check that.  That's useful, too.

    Jason> Given that, if we see EH constructs while compiling, there
    Jason> are two possible conclusions:

    Jason>   1) The user is an idiot, and this code needs EH support,

    Jason> or 2) The user either knows that no exceptions will
    Jason> actually be thrown, or intends to forego the ability to
    Jason> recover cleanly from an error.

    Jason> Your position is that situation #2 can be handled without
    Jason> too much trouble using macros, so we should assume
    Jason> situation #1 and give an error.

Right.

    Jason> I suppose I can be convinced to agree with you about
    Jason> try/catch, but I still strongly disagree about throw specs.

OK.  

I certainly see throw specs as the least problematic from the point of
view of user surprise.

I'm still not entirely happy, though.  The problem is that if code
called from here throws an exception, and you were actually depending
on using an unexpected handler in some way, now you're not going to
get there.  (The unexpected handler was perhaps supposed to reboot the
spaceship, but now it just crashes.  Oh, well.)

I guess I just don't see the point given that we have a preprocessor
extension in C99 (and probably soon in C++) that allows you to
macroize this away, too, with extremely little work.

Still, I'm more than willing to meet you half way.  If we do nothing
now, we have that compromise right?  We already ignore the throw
specs, but we don't ignore try/catch?  That's fine with me.

    Jason> The only reasonable use of throw specs IMO is adding empty
    Jason> throw specs to a function declaration to let the compiler
    Jason> know that the function in question can't throw, for
    Jason> optimization.  

Just curious -- why do you say that? 

Other throw specs allow other optimizations; if you know this function
can't throw `bad_foo' then you know you can eliminate code to catch
`bad_foo'.  You also get useful program validation; if this function
should through only these exceptions, then exception-specifications
allow you to easily test that these things are always true.

(One thing that makes things difficult in C++ is that (for backwards
compatibility) functions without throw specs can throw everything,
rather than nothing.  In some languages, it's the opposite -- then you
can reason rather well about what kinds of exceptions can propogate
from where.)

Why don't you think those are reasonable uses?

    We shouldn't complain about that usage with
    Jason> -fno-exceptions.  Nor should we complain about people
    Jason> redefining ::operator new with the appropriate throw specs.
    Jason> I suppose we could complain about other throw specs, but I
    Jason> don't see any compelling reason to do so; it's simpler just
    Jason> to ignore them all.  Especially since that's the status
    Jason> quo.

True 'nuff.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com