Error Handling in C++

[Axel Gallus]

I am desperately looking for some resources dealing with error handling in
c++.

Don't get me wrong.... I have very detailed knowledge of exceptions,
assertions and invariants,
but what is missing it the following:

1.)
When developing a commercial application, how does the usage of
exceptions and assertions as well as
other mechanisms look like in the development lifecycle and in the
end-product?
E.g. do the developer only use assertions in debug phase? When do they
use assertions when exceptions.
Do they use exceptions for such daily things as to report if some
functions parameters weren't delivered right?
Moreover if performance is crucial, how can that shift the usage of
exceptions, assertions and other mechanisms.

2.)
How does the logic of a more sophisticated error-handler class system
look like?
E.g. how looks a system which capabilities to identify and reporting the
problem to other subroutines/user,
recovering from error and correcting the problem?

3.)
How does a error handler system which should be prepared for
mutilanguage support as well
as concurrency (threads) look like?

I hope someone can give be a hint for a book or other resources like
www-sites which address
this kind of problems it would be great.

Greetings

A.Gallus

 

[JohnQ]

I am desperately looking for some resources dealing with error handling in
c++.

Don't get me wrong.... I have very detailed knowledge of exceptions,
assertions and invariants,
but what is missing it the following:

1.)
When developing a commercial application, how does the usage of
exceptions and assertions as well as
other mechanisms look like in the development lifecycle and in the
end-product?
E.g. do the developer only use assertions in debug phase? When do they
use assertions when exceptions.
Do they use exceptions for such daily things as to report if some
functions parameters weren't delivered right?
Moreover if performance is crucial, how can that shift the usage of
exceptions, assertions and other mechanisms.

2.)
How does the logic of a more sophisticated error-handler class system
look like?
E.g. how looks a system which capabilities to identify and reporting
the problem to other subroutines/user,
recovering from error and correcting the problem?

3.)
How does a error handler system which should be prepared for
mutilanguage support as well
as concurrency (threads) look like?

I hope someone can give be a hint for a book or other resources like
www-sites which address
this kind of problems it would be great.

Is this homework? Sure seems like it.

 

[James Kanze]

I am desperately looking for some resources dealing with error handling in
c++.

Don't get me wrong.... I have very detailed knowledge of exceptions,
assertions and invariants,
but what is missing it the following:

1.)
When developing a commercial application, how does the
usage of exceptions and assertions as well as other
mechanisms look like in the development lifecycle and in
the end-product? E.g. do the developer only use
assertions in debug phase? When do they use assertions
when exceptions. Do they use exceptions for such daily
things as to report if some functions parameters weren't
delivered right? Moreover if performance is crucial, how
can that shift the usage of exceptions, assertions and
other mechanisms.

Typically, any reasonably sized application will use a
combination of mechanisms to report errors. Assertions,
exceptions and return codes serve different purposes, and will
all be used, each according to what is needed. In general:

-- If the error represents a programming error, or a can't
possibly occur error, it's an assertion failure (and
obviously, assertions stay in, even in delivered code). If
the internal state of the program is inconsistent (and if
you arrive in an "impossible" state, it is), then the only
reasonable thing to do is to abort.

-- There are some errors which can't be recovered from. These
depend on the application, of course, but for a lot of
applications, out of memory would be an example. And for
most applications, so would errors during start-up and
initialization---it's usually (but not always) better to
stop immediately, for example, if there is an error in a
configuration file. In such cases, an error message and
exit is the most appropriate behavior. (Not an abort,
because there's nothing wrong with the program.)

-- There are errors which, while not requiring that the entire
process be stopped, do mean that the operation (transaction)
currently in progress be aborted. These are best handled by
exceptions, which propagate the error over many layers of
function calls in a more or less painless fashion.

-- There are more or less everyday errors, which you really
expect (e.g. cannot open file, with a user supplied
filename, or a syntax error in user supplied input). In
many cases, they can be handled more or less locally, and
will occur more or less frequently; they are best handled by
return codes.

-- There are also errors which can occur almost everywhere
during processing: write error to a file, for example. If
these can be made "sticky", the easiest (and often
acceptable) solution is just to ignore them, except that the
level where they were detected, and only test them at the
end of a complete set of operations. Thus, for example,
when writing to an ofstream, you'll usually ignore the
possibility of an error until after the close(), and only
test then.

Note that the same type of error may have different
implications, and call for a different treatment, depending on
the application, or where it occurs in the application. If you
are opening a file whose name was given by interactive input,
and the open fails, you return an error, and the calling code
asks the user for another name; if you are opening a
configuration file whose name was obtained from a command line
argument, you probably don't want the program to go any further.
In such cases, where you cannot decide at the level where the
error is detected, it's probably best to handle it in the least
critical manner reasonable (i.e. as the lowest point in the
above); it's easier to convert a return code into an exception
than vice versa, and of course, if you terminate the program,
there's no way to convert that into anything less drastic.

2.)
How does the logic of a more sophisticated error-handler
class system look like? E.g. how looks a system which
capabilities to identify and reporting the problem to
other subroutines/user, recovering from error and
correcting the problem?

Because the requirements are so varied, solutions tend to be ad
hoc. Most applications will define a global inheritance
hierarchy (based on std::exception), and most will define a
return code type (which triggers an assertion failure if
destructed without being read), but that's about it.

3.)
How does a error handler system which should be prepared
for mutilanguage support as well as concurrency (threads)
look like?

For the most part, errors that don't terminate the program will
be handled in the thread where they occur. At least in the
types of applications I've written; a lot depends on why you are
using threads to begin with.