Printable View
Hi~
I understand that there is an exception throwing mechansim in C++. I was experimenting with it the other day - but can I use it to check for random exceptions, i.e. "An unexpected error has occured."? Because otherwise I'd have to have an idea of every error that could ever happen...
As I cannot create a random error, I'm asking you guys about the theory of it. What does it do?
Thanks ~
Chris Howarth
Segmentation faults? I'm not sure, it probably depends on your compiler.
In-program exceptions? Yes. The catch(...) construct catches all exceptions.
If you want my opinion, your ultimate goal should be to never write a program that prints an error message like "An unexpected error has occurred." Be specific. In the battle of debugging, error messages make all the difference. To answer your question: yes, this is possible if you employ some good design patterns (there is no such thing as a "random exception"). I hope someone at Microsoft is reading this forum...
>Segmentation faults? I'm not sure, it probably depends on your compiler.
Segfaults aren't random, either. If you use good programming constructs, use bounds checking when possible, and check all new allocations, you can eliminate almost all segfaults.
That said, C++'s exception mechanism kind of sucks. I mean, it works, and if you know how to use it right, it can do some very good things for your code, but there are a few things that you have to keep in mind.
In C++, anything can be thrown as an exception. Strings, ints, enums, you name it, you can throw it. What this means, though, is that it's not possible to catch all exceptions and get any information out of them. The only way to catch all possible exceptions is to use the catch(...) construct, and since you can't do anything with the "..." in there, the best you can do is output "an exception occurred in the function," which really isn't all that useful. One way around this is to create your own Exception class and insist that every person on your team use it exclusively.
The other problem is that C++ doesn't require you to declare whether your function throws an exception or not. This means that the only way to know for sure if a function throws exceptions or not is to scour through every dependency and search for the "throw" keyword. The way around this problem is to either a) not work on any particularly big projects, or b) put a comment at the top of every method that throws an exception, including ones simply call methods without catching their exceptions.
Add this to the inherent issues with exceptions (mainly code being skipped in seemingly arbitrary locations), and you have a pretty savage beast.
My point isn't, "don't use exceptions," (I mean, the project I'm on uses them all over the place), but rather, if you're going to use them, make sure everyone on your project knows pretty well what they're doing.
I suggest to have a look at this link to get an idea about the different opinions about exceptions (there are 2 parties: pro & con), booth with good arguments
http://www.scottcollins.net/articles/exceptions.html
Good article. It does a good job explaining why exception-based programming is good (and does not actually cause cancer), but it doesn't really address my issues with C++'s implementation in particular.
My main problems are a) no base exception class, and b) no required "throws" keyword in function definitions. These are two things that Java gets right, IMO, and really make exception-based programming a lot easier.
I don't know java very well. why does "throw" make things easier? you see the throw and you are able to handle all exceptions because you know ... erm ... hm ... oh ... nothing? you have to read the docu to know what to catch and how to get information out of the thing you catched? like as in c++? and code without docu can even be written from scratch (imo)Quote:
Originally Posted by froobly
please tell me if I'm wrong.
What I like about the mandatory "throws" keyword isn't that it gives me specific information about how to handle an exception, but that it protects against stealth exceptions -- exceptions that are being thrown a few function calls down, but that you have no indication they exist. The "throws" keyword doesn't tell you how to handle the exceptions, but it does tell you 100% of the time whether or not they exist.Quote:
Originally Posted by pheres
What Java does do that helps you handle exceptions when you have no idea what you're doing, is provide a base Exception class, that all exceptions derive from. This class contains a string, so at the very least, if all else fails, you can tell the user what went wrong. There's no such thing as an unknown exception, because every exception knows at some level what it is.
Anyway, sorry to have turned this into a bit of a holy war. I don't mean to be some kind of Java zealot. It's just that I really don't like the way C++ does exceptions.
ok, I got what you mean. I hope one of the c++ gurus in here is going to answer your question (and tell us why the world is much better without exception base classes and throw keyword ;) )
The only war I'm in is the war of learning :)
As noted, C++ has the catch (...) construct for such "catch-all" exception handling. C++ simply does not have checked exceptions.Quote:
What I like about the mandatory "throws" keyword isn't that it gives me specific information about how to handle an exception, but that it protects against stealth exceptions -- exceptions that are being thrown a few function calls down, but that you have no indication they exist.
Considering the existence of RuntimeException in Java, I doubt if that really is the case. Its existence would certainly tell you if an exception may be thrown, but its absence would not tell you that an exception cannot be thrown.Quote:
The "throws" keyword doesn't tell you how to handle the exceptions, but it does tell you 100% of the time whether or not they exist.
std::exception would be the C++ near equivalent. All exceptions throwable in the standard library are derived from it. If I do need to write my own exception classes, I subclass an appropriate class in the std::exception hierarchy. The what() member function of std::exception returns a string that should describe what went wrong.Quote:
What Java does do that helps you handle exceptions when you have no idea what you're doing, is provide a base Exception class, that all exceptions derive from. This class contains a string, so at the very least, if all else fails, you can tell the user what went wrong. There's no such thing as an unknown exception, because every exception knows at some level what it is.
Always document in prose the exception specification of a function.
Always document also the exception guarantee of a function:
http://www.boost.org/more/generic_exception_safety.html
The article does not only apply to generic components.
OK, thanks.Of course, yes, but it would be better to have an error message alerting the user if an error did occur, rather than the program crashing.Quote:
your ultimate goal should be to never write a program that prints an error message like "An unexpected error has occurred."
Thankyou! ~
Chrishowarth
So what if you're writing an app that loads external functionality from plug-ins? What if a badly-written plug-in throws some weird exception that you didn't plan for? Sure, you can CATCH the exception without knowing its type, but what are you going to DO with it? The most informative message you could issue would be "The plug-in XYZ has caused an error."Quote:
Originally Posted by UMR_Student
In the real world code works in conjunction with other code you have little or no control over.
Which is still better than "An unexpected error has occurred." At least the end user knows who to blame.Quote:
The plug-in XYZ has caused an error.