I have a question about exceptions.

I don't really understand the underlying purpose of throwing an exception. I know that the programmer can allow for correction of the error without throwing the exception, and they could cause the program to abort without an exception as well, so why exactly throw an exception. Instead of using the try and catch, why not just try and write code that corrects the error or allows the user to correct the error. I know it's necessary and has a useful purpose, but so far I just can't grasp what that is. Any examples of exceptions that are necessary?

>why not just try and write code that corrects the error or allows the user to correct the error.
How? Exceptions are a means of reporting that an error occurred. Writing code that corrects the error implies that you've somehow discovered that there was an error. So if you don't use exceptions, you have to use a functional equivalent, like returning error codes.

>I know it's necessary and has a useful purpose, but so far I just can't grasp what that is.
They're not necessary, but they are an improvement when used correctly. Code written for exceptions doesn't have error handling code intermixed with the meaty goodness (note that error handling usually takes about 1/3 of the code base in an average application). This makes code clearer and shorter. Also, rather than failing quietly for months before exploding in a glorious meltdown, unhandled exceptions will fail predictably, safely, and immediately.

>Any examples of exceptions that are necessary?
There are none. Exceptions can be replaced with a number of error reporting techniques to the same effect.

Stroustrup explains the exception handling mechanism in his book in a very clear way.

What I guess you need to do, besides buying the book ;), is to remember that C++ allows for modularization of your code. A class may know about an error, but not know what to do with it, while the user of that class may know what to do, but not how to detect the error. And speaking of classes, we can say a namespace or an entire library.

The key concepts are thus error reporting (which is usually done by the module being called) and error handling (which is usually done by the caller). C++ Exceptions make that separation allowing a bridge between the two by means of error objects.

For this to make more sense you have to add another agent to your programming experience. You are probably used to looking at your projects as I, the programmer, and Them the users of my program. And yet there is in fact a third Agent. For many things from exception handling to OOP design you should think in terms of class designer, class user and program user. For a lone programmer, the first two may be embodied in one person (the programmer). But you still need to look at things that way, not forgetting that you have two roles and understanding when you are coding for which role.

Take a look at a recent thread on this forums asking about a strange output regarding allocation of memory. The <new> header defines a the new operator and what happens when you try to allocate memory that you don't have.

The Class Designer or the (library designer if you want) knows how to detect when this happens. But what does he know what to do about it? Should he immediatly abort? Should he move on? He doesn't know. He delegates that decision to whoever calls the code. So... he throws an exception. If unhandled that exception will force the code to abort.

Meanwhile, you the User of the Class where trying to allocate some very big arrays. And decided that if the computer where the program is running didn't have enough memory, you should inform the program user and ask him for a smaller number. But how do you know if there is enough memory? You can't obviously wait for the program to crash. It will be too late then. What you do is that you try to allocate and catch std::bad_alloc if it happens. Inside the catch block you do what you set yourself to do; inform the user and request for new input (it's obvious to you the class user, that the designer couldn't ever possibly have guessed this).

That's exception handling in the words of a newbie. Certainly others can correct or add to what I said.

I wouldn't say exceptions are necessary. It's one way of dealing with unusual, unexpected, problems.

For everyday problems like "file not found", you don't usually use an exception.

I think the idea is to move the exception handling "off to the side", instead of cluttering-up the main body of your code.

Thinking In C++ Volume II (FREE online) has an entire chapter on exceptions. I Haven't read it for awhile, so I don't remember exactly what it says. But, there is a section on when to use exceptions, and when not to use exceptions.

Quote:

---

Originally Posted by DougDbug

I wouldn't say exceptions are necessary. It's one way of dealing with unusual, unexpected, problems.

For everyday problems like "file not found", you don't usually use an exception.

I think the idea is to move the exception handling "off to the side", instead of cluttering-up the main body of your code.

---

It's something I'm not sure I agree entirely. Don't take me wrong please. I'm aware it may be the result of my ignorance. But I would certainly like to hear more on this.

You see, exceptions seem to me more a tool for programmers aimed at programmers. If we consider a project in isolation, I would think that yes, it's quiet prossible to delineate our own error handling strategy that is not necessarily implemented in terms of C++ exceptions.

But what about code reuse? Are we sure that our strategy will serve us well in the future if we want to import modules to another project? It's probably very difficult to implement a separation from error reporting and error handling. And perhaps it makes little sense considering C++ provides us with that tool already; Exceptions.

And what about the ever growing world of redistributable software and community development? Doesn't it make sense to make exceptions an important part of the error handling techniques, instead of forcing everyone to adapt to what can possibly be an alien approach, or worst, let anyone choose their own methods?

Exception handling is error handling. Certainly we should not become blind to other possibilities. But whenever I want to report an error at a low level in my design, and I don't know how to handle it, exceptions are the way delegate that decision to those parts of my code at an higher level that are more informed as to take a decision. Why avoid that?

>Why avoid that?
Indeed. But it seems to me that you're confusing exceptions with the more abstract concept of delayed error handling (ie. separation of reporting and recovery). You can implement delayed error handling with any strategy; exceptions just make it cleaner. Your conclusions are okay, but how you reach them is a little screwy in my opinion. ;)

Ok. It had to be something like that; I missread Doug's post.
... and I need a lot more reading on this subject.

It's funny actually. I handled pointer syntax, const correctness, alien new concepts like smart pointers, functors and binders, templates, and many other things that when I took a first look at them I thought I was going to eventually give up.

But of all the things, definitely, I never thought error handling would be the thing that I'm taking more time doing the brain switch.

"Why on earth he spends 34 pages discussing this!?" <--- these were more or less my famous last words when I first started taking a serious look at it a couple of months ago.

Quote:

---

Originally Posted by DougDbug

I wouldn't say exceptions are necessary. It's one way of dealing with unusual, unexpected, problems.

For everyday problems like "file not found", you don't usually use an exception.

---

You could make a case that it is better to have a single, uniform error handling scheme versus mixing exceptions with other error handling schemes such as error codes.

Quote:

---

Originally Posted by Cat

You could make a case that it is better to have a single, uniform error handling scheme versus mixing exceptions with other error handling schemes such as error codes.

---

It is also possible to make a case that it is better for an error handling strategy to employ a range of error reporting methods (exceptions, error codes, assertions) corresponding to severity of the errors to be handled and feasibility of recovering from them.

Often it is said that things like "file not found" should not throw exception, because such errors are to be expected.

The question, though, is, "Who expects them?" A function that receives a file name as a parameter and then is supposed to do something with that file does not expect this file not to exist. The place that expects the file not to exist (or to be in an invalid format) is the place that asks the user for the file name.

As such, there are two choices. Either the place that asks can validate existence and well-formedness of the file. Especially in the case of testing a complicated format, this can lead to enormous code duplication and runtime overhead (the file has to be parsed twice).
Or the place that asks calls into the place that parses and simply catches any exception coming out of it, since that is expected.

So whenever someone tells you, "Don't throw an exception for this, it's expected," keep in mind that expectations are a matter of perspective.

Adding to that, I personally think that some circles use the interpretation of the word "exception" as a case to decide wether or not to use throw. I don't think that was the intention of the language implementator.

Quote:

---

Originally Posted by Mario F.

Adding to that, I personally think that some circles use the interpretation of the word "exception" as a case to decide wether or not to use throw. I don't think that was the intention of the language implementator.

---

Yeah, I use the keyword "class" despite being boorish and uneducated ;)

Well, yes, the notion of expected depends on your expectations.

There is sometimes a case for throwing an exception when a file is not found, for example if the program is unable to function correctly if the file is not successfully read. That is an issue of the programmer expecting the file WILL exist, and the program design relying on that expectation being met.

The more usual argument I've seen for not throwing exceptions with file handling is that various errors (eg not finding a file, encountering end of file, etc) do not have significant consequences. For example, a program that processes a set of files simply goes on to the next file if it can't find one or a program that is processing all the contents of a file would routinely check for end of file indication anyway. In the first case (file does not exist) there is no need to throw exceptions, as the batch processing logic would recover from the error anyway. In the second case (end of file encountered) there is no need to throw exceptions as the end of file condition is a rather obvious point where processing would end, and no further recovery (other than closing the file, which would nominally happen no matter how the processing completes) is needed. I suppose we could argue that this is a matter of expectations (eg it is reasonable to expect that a programmer would do things in this way unless they have a specific reason not to), and then we come into arguments of "common practice". If 95% (to pluck a figure from the air) of all file processing codes can be expected to routinely recover if they don't find a file or if they encounter an end of file, does it make sense to report an error in a manner that is better suited for the other 5% of cases?

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 answer is still the same as before. In general, use exceptions in exceptional situations. It is just important to remember that many factors are involved in what determines whether a situation is exceptional or not.

The file not found example is used assuming the reader understands that the situation is something like a situation where code attempts to open a file with an unchecked, user specified filename for a non-essential file. Of course you can have a file not found error that is exceptional and warrants an exception (Mario F., I think you did recently), but that is not what the assumed situation is referring to.

> The file not found example is used assuming the reader understands that the situation is something like a situation where code attempts to open a file with an unchecked, user specified filename for a non-essential file.

Bah! My bad. Thanks for clarifying that Daved.

Quote:

---

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.

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

Quote:

---

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.

Lets consider the file open issue.

- file name is given by the user (I'm making this ever easy to choose against a throw)
- failure to open the file is non critical. Program can happily move on.

but...

- code to actually open a file is in a different module.

This is my point, grumpy. And where I defend an exception should be throw by the code that opens the file. Certainly, if you don't ever plan to reuse that code why bother with an exception. But can you safely make that decision? Or, is it a good decision design-wise?

The user of the module can easily bypass the exception if he wants to, by checking himself if the file exists... or can use the facilities provide by the module and do a try-catch. Their choice. However the module offers him that flexibility.

Arguably the function call inside the module may return false. It's a pretty easy thing to deal with. But what if they reused the module to handle critical files? Suddenly the user is left with the responsability of cleaning up and aborting, when a rethrow would have been a much cleaner solution.

Quote:

---

Originally Posted by Mario F.

Gosh I'm so confused...

---

Don't feel bad, Mario. I thought I knew a few things about exception handling until I read this thread... Now I need to reevaluate that knowledge.....

Well, I just had an epiphany.

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

There's only one answer to that.

>> 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.

Quote:

---

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 think I can see the light!

That last post is a keeper, Daved. Thanks a bunch. I have a lot of ruminating to do. Started this thread thinking I had it all figured out. Thanks everyone for not having given up :)

Quote:

---

Originally Posted by Daved

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.

---

I don't think this view is realistic. In reality, there is one piece of code called "read_config_file" that opens and parses configuration, and there are two places in the code called "read_core_config" and "read_ext_config" which call read_config_file. For the former, an error of read_config_file is fatal, for the latter, it is not.
How should read_config_file react to an error?

I think it should throw an exception, but read_ext_config would catch it, perhaps log it, but otherwise just carry on. Whereas read_core_config may augment or transform it, but otherwise pass it on.

Quote:

---

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.

---

That module is most likely concerned with reading information from the file, so it cannot continue without error - it would be unable to perform its actions.
I also don't think that "fall back to default values" is a good error handling strategy for explicit requests.
In other words, if I call a module and it can't automatically find configuration and thus uses some defaults, that's fine; if I call a module telling it to use some configuration and it - because some error occurred while using that configuration - falls back to defaults, that would seriously annoy me. Talk about a source of weird bugs down the line. (Why is that config file not in /etc/tomcat-5.5 ? I specifically told it to put the file there.

3 hours later: oh, it fell back to the default of logging to the console, which got swallowed by this startup script here.)
Yes, that actually happened to me. Recently.

>> 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.

Quote:

---

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.

I agree, the STL does use exceptions for virtually all error handling, although the STL, being optimized for speed, does very little error checking or reporting to begin with.