Printable View
I'm still a complete newbie in C++, and i've been wondering... Which is a better way to catch exceptions? using try-catch-throw, or some nested ifs?
Because, at least for me, the try-catch-throw syntax seems really confusing, and I don't see how i could implement it on big functions/classes without making a mess out of my code.
Thanks in advance
Can you give an example of how you would use try/catch/throw in one case and then use nested ifs in that same case instead?
try-catch-throw are good in big projects.
They are usually used for large amounts of code. Depending on your code you could use ifs but I dont suggest it.
Go with the exceptions. they are better.
Quote:
Originally Posted by Daved
Sorry Daved, I don't have any code to show here... It's just a little question =(
Then... if exceptions are better, how can you manage a lot of different exceptions, taking into consideration the catch statement is "organized" by types?
Would a good way of doing this be using int for the argument, and making a lot of ifs, each with its own "error message" ?
one way of doing is to have a file with defined errors, and then just trowing them, and catch them as ints
something like this:
or you could make an exception class and derive all kinds of classes from it. and throw the classes and catch them as exceptions like:Code:#define DivideByZero 23123
...
try
{
...
throw DivideByZero;
}
catch(int e)
{
if(e == DivideByZero)
do w/e
}
Or something similar im not on a computer with a compiler at the moment.Code:class Exception
{
string s; // to store the error message
//other vars/functions if you want
};
class DevideByZero : public Exception
{
//in constructor set s to someting like "Cannot Devide by Zero"
};
...
throw DevideByZero;
...
catch(Exception e)
Exceptions are not necessarily better. It depends on the situation. I don't understand what you mean by try/catch/throw versus nested ifs.
Basically, you should use exceptions if the error is not common or expected. For example, if you have a list of objects and that list should never be empty, then you can throw an exception if you end up with an empty list in code that requires its data. Also, you shouldn't be catching exceptions all over your code. You should only catch the exception where your code handle handle it properly, otherwise, let it automatically move up the call stack. You should probably never catch an exception thrown in the same function.
BTW, you can derive your exceptions from std::exception, and you should catch exceptions by reference, not by value.
http://www.cplusplus.com/doc/tutorial/exceptions.html
I was seeing that about deriving exceptions, but... What's the difference in catching them by reference? Only that you can catch derived classes using the base class name? And why is this?
Sorry for all the questions, and thanks to everyone that has replied so far :)
It's the same as passing objects to functions. It is better to pass a non-simple type by const reference to a function rather than by value to avoid an unnecessary copy. Same way with exceptions where a complex object is thrown. I should have made it clear that catching simple types like int by value is fine like the tutorial shows. For bigger objects, catching by value makes an unnecessary copy.
As far as why you can catch the derived classes using the base class name, it is the essence of polymorphism. If you understand why it is done that way with functions, then you'll understand why that is done with exceptions.
...then exception handling is probably beyond your understanding at this point. You need to learn about pointers, functions, classes, and inheritance first.Quote:
I'm still a complete newbie in C++
No, I mean, compared with everyone else. I already know (or... "have a grasp of") those concepts. But there are certain things that still aren't so clear, and i can't seem to find the answers anywhere