the behavior of g++ 3.3.1 exception

[chenchang]

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),"re source 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?

[Kevin Goodsell]

Re: the behavior of g++ 3.3.1 exception

chenchang wrote:
[color=blue]
> 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";[/color]

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.
[color=blue]
> }
> ~A()
> {
> cout<<"--------------------------~A:"<< i <<"-----------------------\n";
> }
> };
>
> int main(int ,char*)[/color]

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.
[color=blue]
> {
> A b(1);
> throwfunction() ;[/color]

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.
[color=blue]
> cout << "---after throw--------------\n";
> return 0;
> }
>
> According to TC++ 3rd(14.4.2),"re source acquisition is initialization" . I
> think the result should be :
> -------------A:1---------------------
> ------------~A:1---------------------[/color]

That's a possible result.
[color=blue]
>
> but the result is :
> -------------A:1---------------------
> //..there are some message for prompting to dump statck frame.[/color]

I'm not sure if that's a strictly conforming result or not, but it seems
reasonable.
[color=blue]
>
> what is the reason?
>
> In addition, i add try..catch.. in the main:
>
> int main(int ,char*)[/color]

Same problem as other main().
[color=blue]
> {
> try
> {
> A b(1);
> throwfunction() ;
> cout << "---after throw--------------\n";
> }
> catch(...)
> {
> throw;[/color]

This throws an exception that you don't bother to catch.
[color=blue]
> }
> 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?[/color]

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.

[chenchang]

Re: the behavior of g++ 3.3.1 exception

hi kevin:
[color=blue]
> 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).[/color]

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" <usenet2.spamfr ee.fusion@never box.com> wrote in message
news:mMKgc.150$ eZ5.40@newsread 1.news.pas.eart hlink.net...[color=blue]
> chenchang wrote:
>[color=green]
> > 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[/color][/color]
<<"-----------------------\n";[color=blue]
>
> 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.
>[color=green]
> > }
> > ~A()
> > {
> > cout<<"--------------------------~A:"<< i[/color][/color]
<<"-----------------------\n";[color=blue][color=green]
> > }
> > };
> >
> > int main(int ,char*)[/color]
>
> 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.
>[color=green]
> > {
> > A b(1);
> > throwfunction() ;[/color]
>
> 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.
>[color=green]
> > cout << "---after throw--------------\n";
> > return 0;
> > }
> >
> > According to TC++ 3rd(14.4.2),"re source acquisition is initialization" .[/color][/color]
I[color=blue][color=green]
> > think the result should be :
> > -------------A:1---------------------
> > ------------~A:1---------------------[/color]
>
> That's a possible result.
>[color=green]
> >
> > but the result is :
> > -------------A:1---------------------
> > //..there are some message for prompting to dump statck frame.[/color]
>
> I'm not sure if that's a strictly conforming result or not, but it seems
> reasonable.
>[color=green]
> >
> > what is the reason?
> >
> > In addition, i add try..catch.. in the main:
> >
> > int main(int ,char*)[/color]
>
> Same problem as other main().
>[color=green]
> > {
> > try
> > {
> > A b(1);
> > throwfunction() ;
> > cout << "---after throw--------------\n";
> > }
> > catch(...)
> > {
> > throw;[/color]
>
> This throws an exception that you don't bother to catch.
>[color=green]
> > }
> > 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?[/color]
>
> 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.[/color]

[Hans-Christian Stadler]

Re: the behavior of g++ 3.3.1 exception

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

[chenchang]

Re: the behavior of g++ 3.3.1 exception

no, i got the same result even if i change '\n' to flush.

"Hans-Christian Stadler" <none@none.none > wrote in message
news:c606n9$c4c $1@news.cyberci ty.dk...[color=blue]
> 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[/color]

[tom_usenet]

Re: the behavior of g++ 3.3.1 exception

On Mon, 19 Apr 2004 16:02:13 +0800, "chenchang" <baibaichen@soh u.com>
wrote:
[color=blue]
>hi kevin:
>[color=green]
>> 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).[/color]
>
>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![/color]

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

[Rolf Magnus]

Re: the behavior of g++ 3.3.1 exception

chenchang wrote:
[color=blue][color=green]
>> 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).[/color]
>
> 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![/color]

Still, you don't catch the exception, so abort() is called. And abort()
doesn't destroy local objects.

[Dave Moore]

Re: the behavior of g++ 3.3.1 exception

"chenchang" <baibaichen@soh u.com> wrote in message news:<c6012v$66 0$1@mail.cn99.c om>...[color=blue]
> hi kevin:
>[color=green]
> > 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).[/color]
>
> 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."
>[/color]

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.

[Kevin Goodsell]

Re: the behavior of g++ 3.3.1 exception

Hans-Christian Stadler wrote:
[color=blue]
> 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.
>[/color]

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.

[Dave Moore]

Re: the behavior of g++ 3.3.1 exception

dtmoore@rijnh.n l (Dave Moore) wrote in message news:<306d400f. 0404190735.6d5d 8f92@posting.go ogle.com>...[color=blue]
> "chenchang" <baibaichen@soh u.com> wrote in message news:<c6012v$66 0$1@mail.cn99.c om>...[color=green]
> > hi kevin:
> >[color=darkred]
> > > 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).[/color]
> >
> > 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."
> >[/color]
>
> 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.[/color]

This is correct and relevant to OP's example ...
[color=blue]
> 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.[/color]

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