Re: Exception Specification Compromise
Nevin :-] Liber wrote:
On Feb 12,> It's easy to do static checking of throw specifications at compile
time because the compiler knows the throw spec of all the called
functions, because it has to see the prototype before it can compile
the call.
Again, I just don't see how you can analyze this without whole program
analysis, which isn't trivial.
GIven the following:
struct Foo
{
virtual void Bar() const = 0;
};
bool DoIThrow(Foo const& f)
{
try { f.Bar(); return false; }
catch (...) { return true; }
}
So, what does DoIThrow() return: true or false?
Personally, I don't know how to do the analysis w/o looking at *every*
derived class of DoIThrow. What is your "easy" way to figure this out?
With the proposal at hand, f.Bar() has no "throw()" specification and
hence *might* throw, thus DoITThrow *may* return true. It's as much as
saying that "const cannot be checked without whole program analysis".
Anyhow, the discussion is pointless because throw() already *does* have
a meaning. A not very usable one for my purposes, but it does.
And this is still a fairly simple case...
Indeed.
Greetings,
Thomas
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]