Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
On Dec 22, 4:55 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
On 2009-12-22, Vladimir Jovic <vladasp...@gmail.com> wrote:
Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be =BBexception
safe=AB, but only a minority of C++ programmers does so or
even is aware of it.
Why?
The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.
It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false in
so far that if the function calls no other function, or only
calls functions guaranteed not to throw, it doesn't have to be
exception safe.)
For instance:
{
char *p = new char[256];
f();
}
If f throws an exception, this statement block is abandoned,
and the allocated memory is leaked.
Or not. If the application is using garbage collection, it's
not leaked. If the application immediately terminates (and is
in a hosted environment), it's not leaked.
Of course other kinds of resources can be leaked, like handles
to operating system resources such as open files.
And there can be other issues besides leaking. In the end,
you've got to ensure internal consistency for all possible
control flows. When some of the possible control flows are the
result of an exception, then this requirement is called
exception safety.
Leaking a resource is not automatically incorrect. Firstly, it
does not violate any C++ language rule. Allocating memory and
losing the pointer does not trigger undefined behavior.
Whether it is an issue or not depends on the precise situation
in which it occurs. Many C++ programs leak resources by
design simply because they lose references to objects when
terminating by returning via main.
Or by calling exit. (Calling exit does not unwind the stack,
which means that destructors of local variables are not called.)
This doesn't matter if the operating system cleans up the
resources after a program that terminated. Minor resource
leaks in short-lived programs are often not a problem.
More correctly, if the resource will be cleaned up by the
system, and you return to the system, it's not been leaked.
It's only a leak if you don't return to the system, or if it is
something which won't be cleaned up by the system. (Neither
Unix nor Windows clean up temporary files, for example.)
[...]
2) How do you handle errors in constructors?
You set a ``successfully constructed'' flag in the object
which is tested after construction, through some public member
function.
And has to be asserted in every member function, so that you
don't accidentally use an invalid object. (There are cases
where this is valid, e.g. input or output. But they're not the
majority.)
3) Simple example : how would you create a method (or a
function) that reads a value (some random integer) from a
file and returns that value?
There are a few ways. One is to store the integer via a
pointer or reference parameter and return the success/error
indication.
Yes. There are better solutions in C++ (at least in certain
cases). But people were writing robust, correct code even
before there were exceptions.
--
James Kanze