Thread: I have a question about exceptions.

Originally Posted by Mario F.

Gosh I'm so confused...

EDIT: But isn't true that the reason to decide or not to throw should be based solely on who/what is going to handle the error?

- The code that causes the error can handle it. Strong case against exceptions.
- The code can't handle it. Strong case for exceptions.

I'm sorry to keep hitting on the same thing. I'm daft. It's just that my perfect world is crashing with every post you gurus make.

The real world seems to stop being perfect every time gurus attempt to walk on water.

Another criterion for deciding if it is appropriate to throw an exception is criticality of the error (i.e. the consequences if no recovery actions are taken). If nothing will break, there is no need to force the issue should no recovery action being taken. Throwing an exception is a way to force the issue (if the exception is not handled, the program will terminate and, normally, any code that catches an exception will take some recovery actions). Failure to open a non-critical file is one example of a non-critical error. Reaching end of file, when end-of-file is a condition for terminating a loop, is another non-critical error.

Originally Posted by Mario F.

And yet... the seriousness of the error should be a decision of the caller.

Not always. It is often possible, at the point where an error is detected, to know how critical it is even if there isn't knowledge at that point about how to recover from it. For example, failure to dynamically allocate memory is often considered a critical error (when it occurs once, it is a fair bet that hard resource limitations are being reached, and other errors will occur unless some recovery occurs). It is also something that, technically, is recoverable, but the recovery schemes are pretty much outside the control of most programs (eg getting the user to shut down other applications, plugging in additional memory). This is one of the reasons operator new throws exceptions (by default) when it fails: the error is critical (meaning it can only be ignored at peril), but technically recoverable (which means it is not necessary to terminate the program immediately) and usually not able to be recovered from when the error is detected.

>> Another criterion for deciding if it is appropriate to throw an exception is criticality of the error.
I'm not disagreeing, but the criticality of an error is still all part of whether an error can be handled at the point at which it happens. If nothing will break in the current code, then the error can be handled. Handling that error is part of the function or module's expected behavior and is hopefully documented.

>> Lets consider the file open issue.
In explaining that situation, you're looking at if from the wrong perspective. If the code to open the file is in another module, then the facts that the filename came from the user and that the program can happily move on are less relevant. From the perspective of that module the facts are:

- Filename came from calling code elsewhere in the program.
- Calling code may or may not be able to continue.
- Module can definitely continue without error.

My thought: don't throw an exception. That might be debatable, but the point is that you have to look at it from the perspective of the code you are writing. This is not a great example, and it is not what is meant by the file open example.

Here are two file open scenarios that should be more clear:

Scenario 1
- Function gets filename as parameter from the caller.
- Intent of function is to load additional non-essential initialization preferences for application.
- Function uses fstream to attempt to open the file.
- Loading no preferences is a valid result of calling the function.
So, if the file fails to open, the fstream's is_open() function will return false, and the function can handle this by loading no preferences. The function can return false if it failed to load preferences if the designer chooses to do so. The situation is not exceptional.

Scenario 2
- Function gets filename as parameter from the caller.
- Intent of the function is to read in necessary initialization data from a dat file.
- Function uses fstream to open the file.
- Application cannot run without data from the file.
So, if the file fails to open, the fstream's is_open() function will return false, but the function cannot handle this error. It's job is to load required information from a dat file. If it cannot load that information, it cannot do its job and the app cannot continue. It should throw an exception.

Real-world situations can get muddier, but you have to analyze each as it comes and apply the same principles. Is this situation one that can occur easily within the program. Can the error be handled. Can the function accomplish its job anyway, etc.

Originally Posted by Daved

>> Another criterion for deciding if it is appropriate to throw an exception is criticality of the error.
I'm not disagreeing, but the criticality of an error is still all part of whether an error can be handled at the point at which it happens. If nothing will break in the current code, then the error can be handled. Handling that error is part of the function or module's expected behavior and is hopefully documented.

Criticality refers to consequences of the error if not corrected, not to any ability to correct the error at the point where it is detected or "where it happens". If an error is detected by some function/module examining the relationship of some objects (or data, or ...), that is not the same as saying that the either the causes or means of rectifying the error are known to that function or module.

If there are a set of preconditions (i.e. assumptions) for the current code to work correctly, and data provided to that code violates those preconditions, then the current code can detect the error but not necessarily correct it. If the consequences of not correcting that error are likely to be severe, then it is a critical error. If the causes of the error are outside control of the current function or module (eg if the error is caused by a hardware failure), then it may be a critical error that the current function/module cannot correct.

>> I don't think this view is realistic
Of course it is realistic. It is a specific example. Your "in reality" version is just a different example. In order to help people understand the concepts, we should stick to simple (yet plausible) examples that are fairly clear in the expected resolution.

Obviously, as I said earlier, real-world situations can get muddier. It is important to study the muddier situations. However, let's not tear down or confuse the simpler examples in the process, or you run the risk of confusing the understanding brought by those simpler examples.

So, in some cases maybe you want your config reader to throw an exception, and maybe in some cases you don't want your error handling to consist of using default values. That's all good, they're just different examples.

If I'm so sure of what I just said... why then I don't see that all over the STL?

They aren't?

Code:

#include <iostream>
#include <vector>
#include <exception>

int main()
{
    std::vector<int> v(5, 1);
    
    try {
        for (size_t i = 0; i < 10; i++) {
            std::cout << v.at(i) << std::endl;
        }
    }
    catch (std::exception& e) {
        std::cout << e.what() << std::endl;
    }
    std::cin.get();
}

The containers probably also (re)throw a bad_alloc error, at least my vectors do here.