exceptions and stack objects

[John Ratliff]

What happens to objects created on the stack when you throw an exception?

For example, suppose I opened a file for reading with an fstream. If I
perform a read operation and I don't like the result, is it okay to
throw an exception? If I do, will the fstreams destructor get called?
Will the file get closed?

Something like:

void method() {
char buffer[0x2000];
std::fstream
in("smetroid.srm", std::ios_base::in | std::ios_base::binary);
in.read(buffer, 0x2000);

if (in.gcount() != 0x2000) {
// not a valid file
throw FooException();
}

in.close();
}

And yes, I know the final call to close is not necessary.

What will happen if FooException gets thrown? Assume it's just a
derivative of std::runtime_error.

Thanks,

--John Ratliff

 

[Victor Bazarov]

What happens to objects created on the stack when you throw an
exception?

Destroyed in the process of "stack unwinding".

V

 

[Kai-Uwe Bux]

What happens to objects created on the stack when you throw an exception?

Provided you catch the exception, the program will destroy the objects
during stack unwinding.

If you do not catch the exception control is not transfered to an exception
handler and stack unwindind, I think, does not happen.


Best

Kai-Uwe Bux

 

[John Ratliff]

John Ratliff wrote:




Provided you catch the exception, the program will destroy the objects
during stack unwinding.

If you do not catch the exception control is not transfered to an exception
handler and stack unwindind, I think, does not happen.

Well, I don't think it matters what happens if I don't catch the
exception, cause then the program will crash.

But I plan to catch this exception if it ever happens.

Thanks,

--John Ratliff

 

[Ron Natalie]

If you do not catch the exception control is not transfered to an exception
handler and stack unwindind, I think, does not happen.

It's actually unspecified if it happens or not. It might or might not.

 

[Kai-Uwe Bux]

It's actually unspecified if it happens or not. It might or might not.

Is this unspecified or undefined behavior? If it is unspecified, could you
give me direct me to a clause in the standard where it "unspecifies" the
behavior?

I am asking because I wonder how the compiler would, in absence of a
matching catch statement, determine where the enclosing block is and where
to stop the unwinding process. Or is it required to proceed all the way
back to main()? If so, how is that implied by the standard. (I recently
tried to figure out what happens if you do not catch an exception, and it
was a real pain. Obviously, I took a wrong turn somewhere since I convinced
myself that stack unwinding is triggered by transfer of control to a
matching exception handler which requires a catch. Oh well.)


Best

Kai-Uwe Bux

 

[Fred Zwarts]

Is this unspecified or undefined behavior? If it is unspecified, could you
give me direct me to a clause in the standard where it "unspecifies" the
behavior?

I am asking because I wonder how the compiler would, in absence of a
matching catch statement, determine where the enclosing block is and where
to stop the unwinding process. Or is it required to proceed all the way
back to main()?

Stack unwinding will not always end in main(). Examples:

1) Exceptions in a multi-threaded program.
2) Exceptions in a constructor of a static variable declared outside the scope of main.

F.Z.