Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
On 2009-12-22, Vladimir Jovic <vladaspams@gmail.com> wrote:
Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++ code,
all functions need to be written to be ??exception safe??, 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.
For instance:
{
char *p = new char[256];
f();
}
If f throws an exception, this statement block is abandoned, and the
allocated memory is leaked. Of course other kinds of resources can be
leaked, like handles to operating system resources such as open files.
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. 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.
Leaking resource is not necessarily a security problem, either. Firstly,
there isn't any way it can grant an attacker the ability to execute
arbitrary code. At worst, a leak can be exploited to launch a
denial-of-service attack. To exploit a leak which occurs during an
exception, the attacker has to figure out how to get the program to
throw that exception, and moreover, to do it over and over again to
exhaust the available resources. If the exception is fatal, it doesn't
matter; the attacker gets to tickle it once, and the program is gone.
The exception has to be used as an indication of some non-fatal situation
that the attacker can create at will. E.g. suppose that a password
entry prompt uses an exception to indicate that the password was not
accepted. The attacker then simply has to keep trying incorrect
passwords to repeat the leak.
Back to return value vs exceptions.
1)
What happens if you can not handle the error in this method?
Or in the method that called this method?
Or in the method that called the method that called the method where the
error happened?
etc
Then you have to keep returning an indication to the caller. The easiest
way to do this is to consistently adhere to a single convention for
error indication throughout the entire program.
A good example of this technique is the Linux kernel.
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.
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.