Error Handling in C++

Discussion in 'C++' started by Axel Gallus, Aug 9, 2007.

  1. Axel Gallus

    Axel Gallus Guest

    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
    Axel Gallus, Aug 9, 2007
    #1
    1. Advertising

  2. Axel Gallus

    JohnQ Guest

    "Axel Gallus" <-karlsruhe.de> wrote in message
    news:f9dqr3$7r2$-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.
    JohnQ, Aug 9, 2007
    #2
    1. Advertising

  3. Axel Gallus

    James Kanze Guest

    On Aug 9, 3:32 am, "Axel Gallus" <-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:
    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
    James Kanze, Aug 9, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kenneth Keeley

    Error Handling

    Kenneth Keeley, Jul 1, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    371
    Kenneth Keeley
    Jul 1, 2003
  2. VSK
    Replies:
    1
    Views:
    766
    Alvin Bruney
    Jul 29, 2003
  3. Mark Tarver
    Replies:
    22
    Views:
    1,276
    J Kenneth King
    Apr 26, 2009
  4. Peter
    Replies:
    34
    Views:
    1,914
    James Kanze
    Oct 17, 2009
  5. Iñaki Baz Castillo
    Replies:
    1
    Views:
    174
    Iñaki Baz Castillo
    Apr 15, 2008
Loading...

Share This Page