Hi, experts. i write a simple program to test EH in G++:
void throwfunction()
{
throw "test";
}
class A
{
int i;
public:
A(int I):i(I){
cout<<"---------------------------A:"<< i <<"-----------------------\n";
}
~A()
{
cout<<"--------------------------~A:"<< i <<"-----------------------\n";
}
};
int main(int ,char*)
{
A b(1);
throwfunction();
cout << "---after throw--------------\n";
return 0;
}
According to TC++ 3rd(14.4.2),"resource acquisition is initialization". I
think the result should be :
-------------A:1---------------------
------------~A:1---------------------
but the result is :
-------------A:1---------------------
//..there are some message for prompting to dump statck frame.
what is the reason?
In addition, i add try..catch.. in the main:
int main(int ,char*)
{
try
{
A b(1);
throwfunction();
cout << "---after throw--------------\n";
}
catch(...)
{
throw;
}
return 0;
}
the result is:
-------------A:1---------------------
------------~A:1---------------------
//..there are some message for prompting to dump statck frame.
it is the expected result, but why? 9 1313
chenchang wrote: Hi, experts. i write a simple program to test EH in G++:
void throwfunction() { throw "test"; }
class A { int i; public: A(int I):i(I){ cout<<"---------------------------A:"<< i <<"-----------------------\n";
If you are using 'cout', you must have some code you didn't bother to
show us (otherwise your compiler would almost certainly have rejected
the code). Please review FAQ 5.8.
} ~A() { cout<<"--------------------------~A:"<< i <<"-----------------------\n"; } };
int main(int ,char*)
This is not a legal definition of main(). The two arguments to main(),
if used, must be of type 'int' and 'char**' (or equivalent) respectively.
If you aren't using the arguments, just leave them out.
{ A b(1); throwfunction();
This throws an exception that you don't bother to catch. The result is a
call to terminate(), which by default calls abort(). Whether or not
stack unwinding occurs first is implementation-defined.
cout << "---after throw--------------\n"; return 0; }
According to TC++ 3rd(14.4.2),"resource acquisition is initialization". I think the result should be : -------------A:1--------------------- ------------~A:1---------------------
That's a possible result. but the result is : -------------A:1--------------------- //..there are some message for prompting to dump statck frame.
I'm not sure if that's a strictly conforming result or not, but it seems
reasonable. what is the reason?
In addition, i add try..catch.. in the main:
int main(int ,char*)
Same problem as other main().
{ try { A b(1); throwfunction(); cout << "---after throw--------------\n"; } catch(...) { throw;
This throws an exception that you don't bother to catch.
} return 0; }
the result is: -------------A:1--------------------- ------------~A:1--------------------- //..there are some message for prompting to dump statck frame.
it is the expected result, but why?
Why not?
Maybe you should read a little bit more about exception handling. Only
the things constructed during the 'try' block's execution are destructed
as the result of an exception, and that's only required if the exception
is caught. Anything automatic object constructed before the try block
will be destructed as usual, at the end of the scope (or by an exception
caught in an enclosing dynamic scope).
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
hi kevin: Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope).
Please refer to 14.4 The C++ Programming Language (Third Edition):
"The Destructor will be called independently of whether the function is
exited normally or exited an exception is thrown."
it tells me that we need not declare an automatic object in try block!
Sorry, I forgot to say that i am running G++ under the windows.
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:mM**************@newsread1.news.pas.earthlink .net... chenchang wrote:
Hi, experts. i write a simple program to test EH in G++:
void throwfunction() { throw "test"; }
class A { int i; public: A(int I):i(I){ cout<<"---------------------------A:"<< i
<<"-----------------------\n"; If you are using 'cout', you must have some code you didn't bother to show us (otherwise your compiler would almost certainly have rejected the code). Please review FAQ 5.8.
} ~A() { cout<<"--------------------------~A:"<< i
<<"-----------------------\n"; } };
int main(int ,char*)
This is not a legal definition of main(). The two arguments to main(), if used, must be of type 'int' and 'char**' (or equivalent) respectively.
If you aren't using the arguments, just leave them out.
{ A b(1); throwfunction();
This throws an exception that you don't bother to catch. The result is a call to terminate(), which by default calls abort(). Whether or not stack unwinding occurs first is implementation-defined.
cout << "---after throw--------------\n"; return 0; }
According to TC++ 3rd(14.4.2),"resource acquisition is initialization".
I think the result should be : -------------A:1--------------------- ------------~A:1---------------------
That's a possible result.
but the result is : -------------A:1--------------------- //..there are some message for prompting to dump statck frame.
I'm not sure if that's a strictly conforming result or not, but it seems reasonable.
what is the reason?
In addition, i add try..catch.. in the main:
int main(int ,char*)
Same problem as other main().
{ try { A b(1); throwfunction(); cout << "---after throw--------------\n"; } catch(...) { throw;
This throws an exception that you don't bother to catch.
} return 0; }
the result is: -------------A:1--------------------- ------------~A:1--------------------- //..there are some message for prompting to dump statck frame.
it is the expected result, but why?
Why not?
Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope).
-Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting.
I think the behaviour you see is reasonable, because you don't flush
the cout stream.
Maybe
cout << ".. ~A:i .." << flush;
will give the result that you expected.
Hans
no, i got the same result even if i change '\n' to flush.
"Hans-Christian Stadler" <no**@none.none> wrote in message
news:c6**********@news.cybercity.dk... I think the behaviour you see is reasonable, because you don't flush the cout stream.
Maybe cout << ".. ~A:i .." << flush; will give the result that you expected.
Hans
On Mon, 19 Apr 2004 16:02:13 +0800, "chenchang" <ba********@sohu.com>
wrote: hi kevin:
Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope).
Please refer to 14.4 The C++ Programming Language (Third Edition): "The Destructor will be called independently of whether the function is exited normally or exited an exception is thrown."
it tells me that we need not declare an automatic object in try block!
Yes, but this only applies if the exception is caught eventually. If
the exception propogates out of main, then "terminate" is called, and
stack unwinding might not occur. The moral: never let any exceptions
escape from main - to do so is a bug.
Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
chenchang wrote: Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope).
Please refer to 14.4 The C++ Programming Language (Third Edition): "The Destructor will be called independently of whether the function is exited normally or exited an exception is thrown."
it tells me that we need not declare an automatic object in try block!
Still, you don't catch the exception, so abort() is called. And abort()
doesn't destroy local objects.
"chenchang" <ba********@sohu.com> wrote in message news:<c6**********@mail.cn99.com>... hi kevin:
Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope).
Please refer to 14.4 The C++ Programming Language (Third Edition): "The Destructor will be called independently of whether the function is exited normally or exited an exception is thrown."
Please refer to the rest of chapter 14 in TC++PL, specifically 14.7
.... there you will find exactly what Kevin already told you, that an
uncaught exception generates implementation-defined behavior,
particularly with regard to whether or not destructors are called.
The phrase you quoted from 14.4 is only referring to objects that were
in scope when the exception was thrown ... look at the preceeding
example in the book.
Hans-Christian Stadler wrote: I think the behaviour you see is reasonable, because you don't flush the cout stream.
Maybe cout << ".. ~A:i .." << flush; will give the result that you expected.
Please quote the relevant context from the message you are replying to
so that people reading your message know to what you are referring.
Streams are flushed when they are destroyed, so explicit flushing isn't
necessarily needed. However, exiting the program via abort() (via
terminate(), via an uncaught exception) may not destroy existing
objects. In fact, it may be required NOT to (I'd have to check to be
sure). So this could feasibly be part of the problem, but a more general
solution would be to not let exceptions go uncaught.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting. dt*****@rijnh.nl (Dave Moore) wrote in message news:<30**************************@posting.google. com>... "chenchang" <ba********@sohu.com> wrote in message news:<c6**********@mail.cn99.com>... hi kevin:
Maybe you should read a little bit more about exception handling. Only the things constructed during the 'try' block's execution are destructed as the result of an exception, and that's only required if the exception is caught. Anything automatic object constructed before the try block will be destructed as usual, at the end of the scope (or by an exception caught in an enclosing dynamic scope). Please refer to 14.4 The C++ Programming Language (Third Edition): "The Destructor will be called independently of whether the function is exited normally or exited an exception is thrown."
Please refer to the rest of chapter 14 in TC++PL, specifically 14.7 ... there you will find exactly what Kevin already told you, that an uncaught exception generates implementation-defined behavior, particularly with regard to whether or not destructors are called.
This is correct and relevant to OP's example ...
The phrase you quoted from 14.4 is only referring to objects that were in scope when the exception was thrown ... look at the preceeding example in the book.
This is correct, but not relevant to OP's example .. no scoping issues
exist in his code AFAICS .. its just the uncaught exception causing
havoc .. sorry for any confusion This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: E. Robert Tisdale |
last post by:
In the context of the comp.lang.c newsgroup,
the term "undefined behavior" actually refers to
behavior not defined by the ANSI/ISO C 9 standard.
Specifically, it is *not* true that "anything can...
|
by: Farooq Khan |
last post by:
why does Response.Write in a method of code-beind class when called from
inpage code (i.e in <%---%>), after creating object of that class, fails
when called
while it works perfectly ok while...
|
by: John |
last post by:
I'm trying to create a context object similar to the HttpContext that could
be used by business objects independent of the origin or the call (ASP.NET
or standalone).
So I started out by...
|
by: MikeM |
last post by:
We are getting a behavior on a Response.Redirect("SomeUrl", True) that I'm
hoping someone can explain. This all refers to the code snip at the end. By
the way, this is all VB ASP.NET v1.0 code.
...
|
by: Steve Long |
last post by:
I'm working on a project in VB.NET and when a line of code is executed that
throws a nullreferenceexception or some other type of exception, the runtime
just jumps to some other line of...
|
by: Sačo Zagoranski |
last post by:
Hi...
This is driving me crazy and I really hope I can get an answer...
Take a look at the piece of code below (I'm using .net 2.0):
try
{
double pointTime =...
|
by: John Kraft |
last post by:
Hello all,
I'm experiencing some, imo, strange behavior with the StreamReader
object I am using in the code below. Summary is that I am downloading
a file from a website and saving it to disk...
|
by: noone |
last post by:
hi.
I don't use exceptions much in the embedded world, but for my plugin
interface to a hardware MPEG encoder I'd like to, since there are so many
places that the crummy kernel driver can do bad...
|
by: mbeachy |
last post by:
Some rather unexpected behavior in the set_default/set_defaults
methods for OptionParser that I noticed recently:
<Option at 0x-483b3414: -r/--restart>
{'restart': None}
{'retart': False,...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |