In Google C++ Style Guide they state that they are not using exceptions in C++ code at Google. They have reasons for it (“historical” mostly, as usual), but I do not necessarily agree with their view on it. Anyway, exceptions are quite a controversial topic in C++ community, and a must-read C++ Exceptions: Pros and Cons article at CodeProject goes deeper into the subject.
Personally I think that exceptions are really great, although I see how people can get things messy/wrong when using exceptions in inappropriate contexts and/or in inappropriate ways. Recipe to avoid problems? My own short list:
- Use exceptions when they are really needed, i.e. when something exceptional happened
- Understand Exception guarantees AKA Abrahams guarantees (see more at Exception-Safety in Generic Components – Lessons Learned from Specifying Exception-Safety for the C++ Standard Library by David Abrahams)
- Follow Resource Acquisition Is Initialization AKA Resource Initialization Is Acquisition (or RAII/RIIA in short) principle
- Ask the Performance Team (Thoughts from the EPS Windows Server Performance Team) – in their own words “… the Performance team covers a broad range of seemingly unrelated areas such as Core OS Performance, Printing, WMI and Terminal Services. Simply put – we’re a bit of a “catch-all” team. […] Because we cover such a wide spectrum of technology, we see many different types of issues – some more frequently than others. So we thought we should share with the broader technical community. We’ll be sharing troubleshooting tips and technical information on areas of our specialty that we cover.”
- 45+ Excellent Code Snippet Resources and Repositories – it is what it says it is.
Threadsafe Events article at CodeProject explains problems one might encounter with .NET events in a multithreaded environment (not necessarily stating the absolute truth but still). Unfortunately, no-one has figured out the perfect solution, and we will have to choose “the best from all bad solutions” for some time still.
Asynchronous Callback Contexts article by the same author shows possible solution for event cancellation, particularly during object disposal: end-users do not expect components to raise events after they have been disposed or after they have unsubscribed from these events. The author refers to his Nito Asynchronous Library as a way to solve this issue.