Re: Exceptions and Member Initialization
On 10 Mai, 22:15, Tomislav Petrovic <t.petro...@inet.hr> wrote:
I'm reading Stroustrup, 14.4.6.1 Exceptions and Member Initialization
and am a bit confused when trying code provided there....
#include <iostream>
Currently, you also need #include <ostream>, if
you want to output character sequences portably.
using namespace std;
class Y {
public:
Y() { throw new bad_alloc(); }
Hmmh, you have some Java or .Net history, don't you?
Otherwise I don't understand why you don't simply throw
std::bad_alloc just "per value"?!
Y(int) {}
};
class X {
Y val;
public:
X()
try
: val()
{
cout << "Here I am 1" << endl;
}
catch (...)
{
cout << "Here I am 2" << endl;
}
X(int i)
try
: val(i)
{
cout << "Here I am 3" << endl;
}
catch (...)
{
cout << "Here I am 4" << endl;
}
};
int main(int argc, char* argv[])
{
X x1(1);
X x2;
}
I expected that following will be output:
Here I am 3
Here I am 2
However I get this (exception is not caught):
Here I am 3
Here I am 2
terminate called after throwing an instance of 'std::bad_alloc*'
Aborted (core dumped)
g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
If i tried this on VS 2003, I get identical behavior.
In VS 2003 I can get desired by putting return at the end
of catch blocks (this does not compile on g++).
What is correct behavior per specs?
gcc is right, VS2003 (and VS2005-SP1 as well) are
both wrong to accept the return statement in the handler.
To be fair, the standard uses some unfortunatly wording
to express its intend. I would say that is near to a defect:
1) 15/1 says:
"[..] [Note: within this clause "try block" is taken to mean
both try-block and function-try-block. ]"
2) 15/2 says:
"[..] A goto, break, return, or continue statement can be
used to transfer control out of a try block or handler.[..]"
So from (2) one might conclude that the return statement
in the handlers is ok, because the previous note guaranteed
that "try block" can also be the handler. This contradicts
the latter paragraph 15 of section 15.3:
"If a return statement appears in a handler of the
function-try-block of a constructor, the program is
illformed."
Precisely this sentence invalidates the return statement
as illformed code, so gcc is correct here.
Going back to the contradiction of your expectations
and the reality ;-)
Function-try-blocks are special beasts inside c'tors
and d'tors. Indeed the standard says in 15.3/16:
"The exception being handled is rethrown if control
reaches the end of a handler of the function-try-block
of a constructor or destructor. Otherwise, a function
returns when control reaches the end of a handler
for the function-try-block (6.6.3)."
So a c'tor/d'tor function-try-block handler *must*
rethrow the exception, otherwise this would
lead to objects that could violate their post
conditions. If you really *need* to catch this exception,
you could replace Y in X by Y* (or a smartpointer
to Y) and allocate in the function-body[*] inside a
normal try-block. This is ok, if you allow Y to be
optional/nullable and just this happens to be,
if it's pointer value was correctly initialized with 0
in the initializer-list.
Be aware to the difference of other function-try-blocks,
e.g.
void foo() try {
X x;
} catch (...) {
std::cerr << "rest in silence...\n";
return; // Harmless and allowed, has no difference
// in behaviour.
}
which *don't* rethrow the original thrown exception.
And which compilers support it?
Not my older Borland 5.* and neither the VC6
compiler, but I guess that practically all modern
compilers should support this required language
feature.
Greetings from Bremen,
Daniel Kr?gler
[*]: It seems that the upcoming standard seems to
indend to change the notion of "function-body", see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#452
From a user-perspective this is somewhat unfortunate,
because this enforces one to describe the area of what
currently is the function-body, as "compound-statement".
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]