Quote:Original post by Wavarian
SiCrane is right.

Do not mistake exceptions for use as a debugging tool, that's not their purpose.

This said, your debugger should be smart enough to break when an exception is thrown. If it's not, upgrade. If you're using GDB:

(gdb) catch throw                      # break on any exception being thrown(gdb) catch throw my_exception_type    # break on a my_exception_type being thrown(gdb) catch catch                      # break on any exception being caught(gdb) catch catch my_exception_type    # take a guess

GDB's catch can also break on everything from signals to DLL (un)loading to thread forks. Read (gdb) help catch for more information on that.

Exceptions scare a lot of game developers because they hear horror stories of how slow they can be. In all honesty they really aren't that slow at all. If anything the stack unwinding is slow when an exception is thrown, but the whole point is to get things working so no exception is ever thrown.

That said, I use exceptions everywhere. I *NEVER* use return error value. This is because WAY too often error returns are ignored and that causes loss of time (debugging), money (paying the debuggers), moral (who wants to hunt bugs?), etc.

There are proposed ideas of error values that must be read or the program will crash. That's a good idea, but hasn't been solidly implemented and tested in the real world. Even the most promissing versions right now still have major flaws.

So...when do I use exceptions? In exceptional cases. That's what everyone says...let me clerify more: I make the normal case painfully obvious like ReadFile( File & ). If for any reason at all that file cannot be read, it is an exception.

EDIT: Typo

Geeze I have a bad habbit of not justifying my answer. Okay...

ReadFile( ); is incredibly easy to understand. It is self-documenting. If anyone doesn't know what ReadFile( ) does they should be fired. This is a good thing.

And if an exception is thrown, you already know part of the "Why did I get an error?". Because the file cannot be read. So all you need now is "Well why can't the file be read?". That's there the exception comes in.

try
{
ReadFile( );
}
catch( DoesNotExist & e )
{
// couldn't read file because the file does not exist
}
catch( InsufficientPermission & e )
{
// couldn't read file because there was insufficient permission
}

You will notice that those exceptions are also very self-documenting. I added simple comments just to prove the point. After you read the exception type, you knew exactly what went wrong. If you then read the comments you would go "Geeze what a waste of time." That's how self-documenting they are.

They are so easy to understand that you probably dislike the comments. It would be better to not have provided the comments!

And we all know programmers don't like to write comments anyway. So we are hitting two birds with one stone.

Sure you can write enums with error values that are this descriptive also. But the minute any of those possible errors is ignored, you have no idea what could be wrong. No simple self-documentation, no stack trace to the error. Nothin'.

Quote:Original post by The C modest god

Quote:Original post by The C modest god
What is an assertion?

Ok, I have read about assert in bjarne's book.
First, it is some sort of C backward compatability thing?

It came from C, but it's still a valid debugging tool in C++ programs. Basically, if you assert( true );, you're saying: "I expect this to be true. If it's not a serious bug has occured, please tell me so I can track it down better."

Quote:It doesn't work well in templates.

Bullshit, I use them in templates just as easily as I do in other functions.

Quote:It gives the line in which it was called, but that is useless if you encapsulate it, which you propabbly would.

Huh? Elaborate what you're talking about?

Quote:It just calls a function? it would not call all the destructors?

In release mode, it does nothing. In debug mode, it halts the execution of the program and tells you where it's happened.

Quote:So it is not suitable to deal a bug which happened in the end user's computer,

Correct to some degree - end users should be getting things compiled in release mode - which means none of the asserts will trigger. It dosn't clean up very nicely, but it does find problems in your code very nicely, which is it's entire point.

Quote:So I don't see why not to use exceptions to catch logical bugs (which usually develope later to a much horrific bugs) on the end user's computer.

Exceptions are for error occurances, not necessairly bugs. For example, not being able to load a file because it does not exist is not a bug - but it may be an exception, especially if the program can't continue without it. Exceptions are for errors that need to get "handled".

An example of a bug would be a pointer to the screen being NULL when it shouldn't. Then you would likely use an assert, rather than trying to display an error message on the screen... when you don't know where the screen is. Asserts are for errors that need to be pointed out, and can't/shouldn't be handled.