Re: is such exception handling approach good?
On Dec 21, 6:52 pm, George <Geo...@discussions.microsoft.com> wrote:
Two more comments,
1. I am surprised to learn that if there are exceptions destructor, the
process will be terminated. Is it also true for development C++ applicatio=
n
Visual Studio environment? If yes, I must be careful.
So the C++ language guarantees that it will call terminate() at this poi=
nt, and
terminate() kills the process. Bang you're dead.
Yes, you must be careful to not spit out any exception from your
destructor.
2. Using smart pointers can avoid the issue of free memory. But can not
avoid this exceptions when we free other type of resources, like file hand=
le
(e.g. if the file to close in destructor is unexpectedly deleted?). Any
comments?
If the file handling APIs or file stream objects close() is not a
nothrow operation, i.e. if they can throw, you must catch that
exception (and any other exception that might arise out of your code
in the destructor) in the destructor body.
MyClass::~MyClass()
{
try
{
//some operation that can throw
}
catch(...)
{
//do whatever but don't do anything that can itself throw
}
}
fstream::close() can throw an exception (there are certain failure
states, only to which, an exception is associated - not to all - I am
not sure of the details) . So, you should have a handler for the
close() call in the destructor.