Exceptions are a case in hand. Google's style guide specifies that they do not use exception handling in their code, with the exception of code that's using Windows ATL and COM classes which use exceptions. Google's reason for not having exceptions is because it would ask too much of their existing code. Exceptions add a cost to the code and to callers of functions which have to handle exceptions caught from above.
I'm in two minds over this; I do use exceptions but there's a lot of code written that manages without exception handling. Look at all the apps written in C for instance. Has anyone got anything to add?
- Link to C++ Programming Tutorials
PS. Thanks for the comments on Challenge 28. I'm reviewing it.


It is my personal experience that introducing exceptions significantly increases the risk of crashes in your end application. Simply because it’s so easy to forget a try catch block.
Conceptually however I think that exception are superior to error return values. It allows you decide at which level in your call stack you want to deal with an error. I think that’s a great feature.
I’ll take exceptions over return codes any day. I understand their point about legacy code not mixing well with exceptions, but to ban it from new code seems heavy handed.
I suggest to always catch exceptions especially since they can help you to debug a difficult problem since you do get frameworks that allow you to log exceptions. Without logging you don’t know what happens, why is a peace of code breaking? Because C doesn’t have proper exception handling (vs C++) is the reason why its so difficult to debug etc.
Don’t use exceptions when you want your code to perform in realtime applications. There is measurable overhead in the runtime as well as the fact that you cause your library users to handle your exceptions. Only when you are writing a high level library is this really okay, and never at real time.