Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Error Handling in C++

Reply
Thread Tools

Error Handling in C++

 
 
Axel Gallus
Guest
Posts: n/a
 
      08-09-2007
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








 
Reply With Quote
 
 
 
 
JohnQ
Guest
Posts: n/a
 
      08-09-2007

"Axel Gallus" <(E-Mail Removed)-karlsruhe.de> wrote in message
news:f9dqr3$7r2$(E-Mail Removed)-karlsruhe.de...
>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.


 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      08-09-2007
On Aug 9, 3:32 am, "Axel Gallus" <(E-Mail Removed)-karlsruhe.de> wrote:
> 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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
signal handling and (structured) exception handling Peter C++ 34 10-17-2009 10:03 AM
python list handling and Lisp list handling Mark Tarver Python 22 04-26-2009 09:36 PM
Is faster handling hexadecimal values than handling chars? Iñaki Baz Castillo Ruby 1 04-15-2008 09:04 AM
Global Error handling in Applicatio_Error() of Global.asax VSK ASP .Net 1 07-29-2003 03:12 AM
Error Handling Kenneth Keeley ASP .Net 0 07-01-2003 03:45 AM



Advertisments