Nexus, In the link I didn't say it was my advice, but I precise that it's the reasons why the traditional game companies working with consoles forbid (or are not able to use) exceptions.
I partially agree with a lot of those reasons but I think it's a case by case basis so I do use exceptions as last resort "i don't know at all what to do here" error message, and most exceptions I handle I only log them.
But that's because I have control over the project, my projects are not cpu-bound (yet), and I'm targetting PC, not low-memory, poor latency consoles.
Now, people often say that if you compare error checking with exception, you will have the same cost, but it's beside the points: in most console games you MUST NOT have errors, you just have inputs that are predictable and you cannot allow any show-stopper problem to be perceptible by the user. The only way to do that is to have a "correct" applcation, that is really hard to do. So instead of havig the program checking errors, the programmers do it (with a QA) and the final result have no checking at all (on consoles at least).
Also, know that having exception does have a cost without even throwing anything in your program. That you want or no to pay the price of using exception is up to your specific case. When I have choice, I do, but on some hardware I can understand that it's a problem.
Finally, I suggested in the beginning of this thread to have some macro that allow the library both to provide exception and/or asserts. That way the user choose for his specific case.
Someone (I dont remember if it's in this thread or even in this forum) noticed that the new standard libraries does provide error checking as well as exceptions, because sometimes you want to check, sometimes you want to crash, and sometimes you want to never get in this case, even if it's possible.
Let the user choose. It's easy to do with macros actually.