Exceptions

[n4nature]

I know that Exceptions are used to handle exceptional conditions in a program. So if an exception is caught, the condition can be rectified in the catch clause.

I have seen a plenty of examples for just logging the error message in the catch clause (when an exception arises). Can you someone give an example of an exceptional condition and a possible rectification of it in the catch clause?

Below is a function that throws and catches an exception. If a condition arises that could be fixed in the catch clause, how can that be coded?

void doSomething()
{
  try 
  {
    someFunction();               // may throw an exception
  }
  catch (exception& ex) 
  {                                        // catches the exception&;
    ...
  }
}

[LoLFactor]

I'm no expert, but i believe that defeats the purpose of exceptions. Yo use them to have a safe way to handle the unpredicted without hanging the application whilst having a good way to categorize errors. What you suggest is having a second chance at doing something that is prone to error, so why just 2 chances at doing something when you can have even more:

bool isgood = false;
do{
    isgood = someFunction();
} while(!isgood);

I know that is ridiculous, but i'm trying to make a point. If an error should occur, i don't think exceptions are to be thrown so that the application can continue like nothing happened, but rather solve any problems that error might have caused and possibly exit. It's not that hard to double-click the application again, you know.

[kbw]

I concure with the above and would like to add coulpe of things.

You should always catch a const& unless there's a reason not to.
e.g. catch (const exception &ex)

There are two models for general exception handling, the termination and resumption models. C++ exception supports the termination model as it was determined that ultimately, that's what was required.

This means that if you want to use the resumption model, you need to sort of do it yourself. Which makes your template code above unsuitable. Usually the code is gratuitous and you're better off doing the attempted recovery with a loop with error codes rather than exceptions.

[n4nature]

Your arguments sounds right on the money.

[PanGalactic]

bool try_again;
do {
    try_again = false;
    cout << "Filename: ";
    string filename;
    cin >> filename;
    try {
        do_something(filename);
    } catch (file_not_found& ex) {
        cerr << "That file doesn't exist." << endl;
        try_again = true;
    }
} while (!try_again);

[kbw]

Remember there's a runtime cost in using exceptions and a static size cost in including the facility.

Further more, they can mask the source of errors and context information in a core dump.

[PanGalactic]

Remember there's a runtime cost in using exceptions and a static size cost in including the facility.

And they are immensely useful.

Further more, they can mask the source of errors and context information in a core dump.

And used properly they can protect against and clearly indicate the source of coding errors. Code that uses exceptions well can eliminate the "walking dead" stage that frequently lead up to a core dump which can also mask context information about what actually went wrong.

Both arguments have merit. Programs written with a keen use of exceptions are generally much more robust. Those that implement exceptions haphazardly tend to do little more than make problems hard to find.

[bnolsen]

PanGalactic, I'd have to say, the example of user input being bad isn't exceptional.
Biggest problem with exceptions is trying to define what exceptional really means.
Bad input from external sources is by no means exceptional...its to be expected.

[n4nature]

Following is a Stack class

Stack
{
    int nelems;
    int top;
    T* v;
public:
    int count();
    void push(T);
    T pop();
    
    Stack();
    ~Stack();
    Stack(const Stack&);
    Stack& operator=(const Stack&);
}

There is a leak in this Copy constructor because of exception. Can anyone point it out? Thanks.

template
Stack::Stack(const Stack& rhs)
{
    v = new T[nelems = rhs.nelems];
    if(v == 0)
    {
        throw ""out of memory"";
    }
    if(rhs.top > -1)
    {
        for(top = 0; top <= s.top; ++top)
        {
            v[top] = rhs[top];
        }
        --top;
    }
}

[jsmith]

Line 5 will never be true, since you are using the throwing version of new. If new fails, it will throw std::bad_alloc and not return NULL, so lines 5-8 are pointless.

[n4nature]

jsmith,

I found the above piece of code from a famous paper found here: http://ptgmedia.pearsoncmg.com/images/020163371x/supplements/Exception_Handling_Article.html

If you see skim through section entitled "Exceptions Thrown by T", author explains why there is a leak. He actually skips your explanation and goes a step further and says that when the exception is thrown, it goes to the function calling copy constructor and since the exception came from a constructor, the calling function assumes there is no object created and the memory assigned by new within the constructor is lost. My point is that, the memory is not successfully allocated in the first place, because only then the constructor will throw an exception and if it is not allocated, then there is no leak.

Am I missing something here?

[kbw]

In this case, it's all ok as v was never allocated anyway.

You'd have a problem if you had two allocations, where the first succeeded and the second one failed.

[z05DSL3A]

template
Stack::Stack(const Stack& rhs)
{
    v = new T[nelems = rhs.nelems];
    if(v == 0)
    {
        throw ""out of memory"";
    }
    if(rhs.top > -1)
    {
        for(top = 0; top <= s.top; ++top)
        {
            v[top] = rhs[top];
        }
        --top;
    }
}

If an exception is thrown at line 13, the calling function will think that the constructor has failed and cleaned itself up. However v will not have been deleted, hence a memory leak.

[kbw]

Quite right. That is a case that's missed in one of Scott Meyer's Effective C++ examples.

[n4nature]

@GreyWolf: Author says that the code is problematic as is. Here, line 13 does not throw an exception. It checks for rhs.top and takes care in the for loop to not exceed that value. Why then would it need to throw an exception at line 13?

[z05DSL3A]

The assignment operator of what ever class is in the stack may throw.

Consider an exception thrown by the assignment operation in the for loop of the copy constructor: