Exceptions: how far do you go?

[Disch]

I'm just curious as to how heavily the users here use exceptions and exception handling. I don't use them much myself, currently, but I am making a lot of changes in my coding style lately (getting more familiar with exceptions, templates, and other areas of C++ I hadn't really gone into much before).

Exceptions for devestatingly fatal errors (like failure to allocate memory) seem like a no brainer, but you can take them much further. I'm just wondering if it's wise to go further with exceptions or if that would be disruptive for code readability or would hinder performance (I've heard that heavy use of exception handling tends to produce slower code -- but I took that with a grain of salt.. it sounds rather fishy and it was just an offhand remark without any supporting evidence).

Exceptions for common errors, like failure to open a file. Or even trying to read past EOF. Invalid params passed to a funciton... or any kind of problem in a function that would result in failure.

How heavily do you guys use exceptions? What are your thoughts/opinions? I'm just looking for general feedback and ideas here so anything would be great.

Thanks in advance.

[Bazzy]

Exception handling should cause some overhead.
I usually prefer to validate stuff in order to avoid exception rather than catching them.
As C++ standard library provides everything you need to avoid exception and C standard library provides everything you need to cause exception I often write my own version of function coming from the C library

[Disch]

While searching for input on the subject I found this page on google:

http://www.parashift.com/c++-faq-lite/exceptions.html

A very interesting read for anyone else interested in this topic. It makes some pretty good points for opting for exceptions over error code checking.

edit:

but then near the end says that using exceptions to replace return codes is a bad idea o_O. hrm

[jsmith]

Exceptions are pretty much required if you are overloading operators (and they can fail) or if construction of an object can fail. In both cases you are restricted to what you can return from the function, so exceptions provide the only means by which to report errors.

Exceptions are also very handy when you are deep into nested function calls as propagating error codes back up requires a lot of coding and can detract from readability.

Otherwise, exceptions should be used, well, for exceptional cases. Failure to open a file, for example, could be considered an exceptional case in a lot of circumstances, but not necessarily all.

Now, IMHO, I think exceptions are terrible for handling things like out of memory. When the system runs out of memory, chances are the system is in an unstable state, and you have to be extremely careful that you don't try to allocate any memory whatsoever while throwing/handling std::bad_alloc or any exception class you might have written. But then again, I'm not sure there is any reasonable programming advice that can be given, in general, on how to handle out of memory conditions.

A general rule is that your code should not be absolutely littered with try-catch blocks. Either your design is flawed or you are trying to use exceptions to handle too many common error cases. The general theory is that a few well-placed try-catch blocks should be able to handle everything. There is a penalty you pay for writing try-catch blocks.