Re: Exception Specification Compromise
On 13 Feb., 04:39, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
In article
<6bb964cd-04bb-49b0-b344-a17a2e943...@b7g2000yqd.googlegroups.com>,
ThosRTanner <ttann...@bloomberg.net> 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?
And this is still a fairly simple case...
I can't respond for ThosRTanner, but my understanding is many here
simply want a signature on a function, "nothrow", that as an effect
forbids throwing an exception or calling a function that might throw.
So effectively only nothrow functions can be called outside a try-
catch block.
The effect would be, of course, that in most interesting cases the
function-body would effectively look like:
{
try
{
do_something
}
catch (...)
{
exit();
}
}
instead of the simpler
{
do_something
}
of a function with a throw() specifier.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]