Exceptions
An exception is what happens generally when something goes wrong, for example, if I created a rational class, and the denominator was zero at some point, I would probably cause it to throw an exception because of that(being the number at that point is undefined).How to deal with exceptions is easy though, you place the code that you want to attempt to do, in a try block , and then try to catch exceptions. For instance:
at least I think that is how it works in C++, not quite sure, I have more experience with exception handling in java. And that is just to create something from the class Exception, make your methods throw the exceptions, and then catch them where appropriate. I hope this information helps you.
#include <iostream>#include <exception>using namespace std;int main(int argc, char* argv[]){try{//place any stuff that you want to try here.}catch(const exception& e){cerr<<"Warning: "<<e;}at least I think that is how it works in C++, not quite sure, I have more experience with exception handling in java. And that is just to create something from the class Exception, make your methods throw the exceptions, and then catch them where appropriate. I hope this information helps you.
I was just reading the section about exception handling in the book, but I''m not sure I completely get the concept. How should we use it in our code? Would it be a good idea to, let say, put try blocks in all our functions, class methods, main() etc.?
You fight like a dairy farmer.
You fight like a dairy farmer.
From what I understand, exceptions are meant to be used in places where something like a function could fail under normal operating conditions , unlike assertions which are meant to detect things that shouldn't happen at all.
Example:
A function to read a file could throw an exception if the file is missing or corrupted. The higher level function that called it could then decide what to do...is this a fatal error, or can we ignore it, retry, etc? The low level file reading function shouldn't have to know what to do, since it could be reading an important file, or a not so important one. By throwing an exception, it lets the higher level function (which catches the exception) decide how to handle things. This removes the need to design all kinds of special cases into your low level functions.
There is apparently some overhead on functions that throw exceptions, so you don't want to wrap everything in try blocks, just the things that could perceivably fail through no fault of the application. You can even specify throw() on a function's definition to let the compiler know that this function doesn't throw exceptions, and the overhead needed to unwind the stack in the case of an exception won't be added to that particular function. At least, that is how I understand it. Someone correct me if I'm worng please.
[edited by - SpaceRogue on July 2, 2003 8:55:32 PM]
Example:
A function to read a file could throw an exception if the file is missing or corrupted. The higher level function that called it could then decide what to do...is this a fatal error, or can we ignore it, retry, etc? The low level file reading function shouldn't have to know what to do, since it could be reading an important file, or a not so important one. By throwing an exception, it lets the higher level function (which catches the exception) decide how to handle things. This removes the need to design all kinds of special cases into your low level functions.
There is apparently some overhead on functions that throw exceptions, so you don't want to wrap everything in try blocks, just the things that could perceivably fail through no fault of the application. You can even specify throw() on a function's definition to let the compiler know that this function doesn't throw exceptions, and the overhead needed to unwind the stack in the case of an exception won't be added to that particular function. At least, that is how I understand it. Someone correct me if I'm worng please.
[edited by - SpaceRogue on July 2, 2003 8:55:32 PM]
Hmm but the normal way that I handle errors is usually w/ the use of if statements for checking conditions. If something is wrong, say like file open failed, then I would print something on the screen to let the user know and finally decide whether continuing is possible or just bail out completely.
This was how it was taught to me before I started looking into exception handling recently. So I''m kind of having a hard time getting the idea behind using exception handling and why one would choose to do it this way.
Thanks
You fight like a dairy farmer.
This was how it was taught to me before I started looking into exception handling recently. So I''m kind of having a hard time getting the idea behind using exception handling and why one would choose to do it this way.
Thanks
You fight like a dairy farmer.
Greatwolf,
Exceptions are essentially a replacement for your method of using if statements to check error conditions.
I guess the advantages of exceptions are that if you forget to check an error condition in a calling function, your program could suffer a major meltdown. Exceptions must be caught or they will unwind the stack and end the application (Ever seen those "unhandled exception" error messages?
The nice thing about exceptions is that they do just that, unwind the stack and call destructors along the way. Simple if statement error checking would seem a great deal more problematic for large programs because it lacks that those features.
Here''s an article that does a decent job of explaining exceptions (in my opinion).
http://gethelp.devx.com/techtips/cpp_pro/10min/2002/June/10min0602.asp
Exceptions are essentially a replacement for your method of using if statements to check error conditions.
I guess the advantages of exceptions are that if you forget to check an error condition in a calling function, your program could suffer a major meltdown. Exceptions must be caught or they will unwind the stack and end the application (Ever seen those "unhandled exception" error messages?
The nice thing about exceptions is that they do just that, unwind the stack and call destructors along the way. Simple if statement error checking would seem a great deal more problematic for large programs because it lacks that those features.
Here''s an article that does a decent job of explaining exceptions (in my opinion).
http://gethelp.devx.com/techtips/cpp_pro/10min/2002/June/10min0602.asp
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
