Exception Handling and Refactoring Question ...

Discussion in 'C++' started by Master of C++, Feb 19, 2005.

  1. Hi,

    I am writing a simulation package in C++, and so far I've written about
    8000 lines of code and have about 30 classes. I haven't used C++
    exceptions so far (for various reasons). The only two "resources" I use
    are memory and file I/O and whenever there is a memory allocation
    failure or file I/O failure I just simply call a custom assert-type
    function to check, print a error message and abort. This seems to be OK
    for now (for the simulator base development), but when I start writing
    a GUI to the simulator, I would require a more graceful way to handle
    such exceptional situations.

    Now, I am reading all the good things about C++ exception handling and
    I am considering refactoring my code to use try-catch type exception
    handling. Agreed, I should have thought about this before I started
    writing a single line of code (my programming skills were much inferior
    then) - But now that I've come this far, is it worth to do the
    refactoring ?, or is it even possible without a complete redesign of
    everything ? (because I've read in many places that exception handling
    should be tightly coupled with the overall design). My other option is
    to expand on the custom assert-type function to do more than just
    display an error message and abort.

    Any suggestions, pointers or references will be greatly appreciated.

    Thanks,
    Vijay.
     
    Master of C++, Feb 19, 2005
    #1
    1. Advertisements

  2. Master of C++

    Cy Edmunds Guest

    I suggest you use ASSERT for errors which could only be caused by
    programming errors and exceptions for errors which can be caused by
    incorrect user input. The whole point of ASSERT is to help you with your
    software testing. Since it drops out in the production code it is of no use
    to the end user. Exception programming can be used to facilitate automatic
    recovery (difficult but necessary in mission critical applications) or just
    to make Good Error Messages -- "GEMs" (much easier).

    You mention resources as if they were the only source of errors but any
    useful software I ever saw is vulnerable to incorrect user input. Exceptions
    can be a good way to deal with that problem, but considerable thought must
    go into it. If your objective is just GEMs, you must ask yourself if your
    end user is going to be able to figure out what he did wrong based on the
    message you are giving him. I wish the programmers of some of the software I
    use had thought about this a little more.

    A console mode program which was just going for GEMs would look like this:

    int main()
    {
    try {
    start_running();
    } catch (std::exception &e) {
    std::cerr << e.what() << '\n';
    }
    }

    Just derive all of your exception classes from std::exception and this is
    it! In principle you don't need to write any other try blocks in the entire
    program. Can't get much simpler than that.

    Google for "programming by contract" to see some interesting ideas about how
    to organize ASSERT programming.

    HTH
     
    Cy Edmunds, Feb 20, 2005
    #2
    1. Advertisements

  3. Master of C++

    GB Guest

    If you are going to use the standard library exception classes the way
    they were intended, then errors that occur in the environment of the
    program, such as user errors, device I/O errors, or resource errors,
    should be derived from std::runtime_error, not std::exception. Logic
    errors of the type traditionally represented by assertions should derive
    from std::logic_error (if you want to use exceptions for this). I would
    expect to find this sort of exception primarily in library code that is
    intended to be widely reused and must perform parameter validation
    without asserting.

    Gregg
     
    GB, Feb 20, 2005
    #3
  4. Master of C++

    GB Guest

    If you are going to use the standard library exception classes the way
    they were intended, then exception classes representing errors that
    occur in the environment of the program, such as user errors, device I/O
    errors, or resource errors, should be derived from std::runtime_error,
    not std::exception. Exception classes representing logic errors of the
    type traditionally represented by assertions should derive from
    std::logic_error (if you want to use exceptions for this). I would
    expect to find this sort of exception primarily in library code that is
    intended to be widely reused and which must perform parameter validation
    without asserting.

    Gregg
     
    GB, Feb 20, 2005
    #4
  5. Master of C++

    Cy Edmunds Guest

    You have confused the type being thrown with the type being caught. A
    std::runtime_error *is* a std:exception -- all exception classes in
    <stdexcept> are derived from std::exception. Hence the code I posted will
    catch a std::runtime_error as well as any other std::exception.

    However, this brings out an important point: if you write the catch phrase
    as

    catch (std::exception e)

    the actual exception will be bit sliced down to a std::exception and the
    polymorphic behavior will be lost.
     
    Cy Edmunds, Feb 21, 2005
    #5
  6. Thanks for your respones ! I am more clear than before about
    exceptions. The general idea I am getting is that exceptions must be
    used very judiciously (for truly exceptional situations) because they
    can be easily misused. For other cases, I will go with with the good
    ol' assert (as I am developing a whole package instead of a generic
    library).

    Thanks,
    Vijay.
     
    Master of C++, Feb 21, 2005
    #6
  7. Master of C++

    GB Guest

    I didn't confuse anything. You said "Just derive all of your exception
    classes from std::exception". This is not in general good advice. I know
    how catching by reference polymorphically works. In fact that is why
    advising to derive from std::exception is not good advice.
    Yes, that is true, but I didn't see anyone suggest catching that way. In
    your previous post you were catching (std::exception&) which is almost
    correct. In general, you should catch by const reference where possible.

    Gregg
     
    GB, Feb 21, 2005
    #7
  8. Master of C++

    Cy Edmunds Guest

    With the code I posted it wouldn't be correct to say that one must use
    std::runtime_error -- any std::exception will work. And using or deriving
    from std::runtime_error *is* deriving from std::exception, consistent with
    my advice.

    Looking at it another way, I did NOT say to NOT use std::runtime_error as
    the actual exception to be thrown.
    Nonsense. An exception object needn't be protected using const for the
    simple reason that the code which threw it has already been unwound. If the
    catch phrase modifies it there can be no side effects. Hence the exception
    belongs fully to the catch phrase which can do with as it pleases.
     
    Cy Edmunds, Feb 21, 2005
    #8
  9. Master of C++

    GB Guest

    If you derive directly from std::exception, you have to either catch
    your exception explictly, or catch all std::exception objects. You lose
    the ability to catch your exception by catching only the
    std::runtime_error subset.
    No, it is not nonsense. If you don't catch by const reference, you will
    fail to catch an exception that is a const object.

    Gregg
     
    GB, Feb 21, 2005
    #9
  10. Master of C++

    Cy Edmunds Guest

    Nonsense. An exception object needn't be protected using const for the
    Perhaps you could show a code example.
     
    Cy Edmunds, Feb 22, 2005
    #10
  11. Master of C++

    GB Guest

    If I did, it would only demonstrate that I was wrong :). Furthermore,
    in an attempt to demonstrate how modifying an exception object in a
    handler could cause a side effect, I learned of another misconception I
    had. I thought the following code would print 2 instead of 1:

    #include <iostream>

    int e = 1;

    int main()
    {
    try {
    throw e;
    } catch (int& e) {
    ++e;
    }

    std::cout << e << std::endl;
    }

    Both gcc 3.3 and Visual C++ 2005 beta print 1. Apparently a copy of the
    exception object is made even if it is caught by reference. I did not
    know this.

    Gregg
     
    GB, Feb 22, 2005
    #11
  12. * Cy Edmunds -> Gregg B:
    There is an issue here relating to "soft" versus "hard" exceptions; the
    same issue reflected by the division of the exception class hierarchy in
    some other languages such as Java and C#.

    Catching std::exception in the 'main' function is OK. Catching std::exception
    at lower levels might run the risk of catching e.g. std::bad_alloc (or worse).
    Yes, mostly one does not care what exception is caught, mostly all exceptions
    are in practice equal, but some are more equal than others...

    However, as with many in things in C++ it's all about convention, and if there
    isn't a reasonable convention being rigorously followed then what you do or
    don't do doesn't matter: the non-conforming code makes all efforts
    at sane exception handling moot (in my humble opinion).

    I gather he's referring to what I tried to sketch above: if even _one_ "soft"
    exception class is derived directly from std::exception then that might
    necessitate catching std::exception instead of std::runtime_error at low
    levels, rendering a convention designed to let through "hard" exceptions
    impotent.

    Well, for standard exceptions:

    * Not using const indicates that there is an intent to modify.

    On the other hand, some non-standard exceptions such as MFC exceptions must
    be modified by the handler.
     
    Alf P. Steinbach, Feb 22, 2005
    #12
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.