Quote:Original post by Antheus Exceptions should generally be used for unrecoverable errors.
Quote:Original post by Windryder The problem with the traditional "return error code" approach is that the function that can fix the problem might be 10 levels up in the call stack. ... So to sum it up, exceptions should be caught where the error can be handled.
These are somewhat conflicting philosophies of exception usage. Windryder's is the one that makes the most sense to me. What's the benefit of using a return value for a "recoverable" error, when the error has to be passed four or five functions back down the stack to be "recovered", and all the conditional logic in between has to be read and maintained? There's also the situation where you want to actually return something, and the Null Object pattern won't work.
Anyway, I have a big try-catch in main to catch big errors, and then a few scattered about close around functions I know might throw something. It's good to catch errors close to where they're raised. I could probably do better at that, along with handling issues like failing to parse level files more gracefully.
Edit: didn't mean to use the angry icon.
[Edited by - theOcelot on May 6, 2010 11:55:21 PM]
Just a heads up, all C++0x compilers (like Visual Studio 2010) have integrated TR1 into the standard namespace. Rather than using auto_ptr or Boost smart pointers, you can (probably should) use std::unique_ptr and std::shared_ptr.
Really, I want to know. What's the balance between "use exceptions for exceptional circumstances" and the practical avoidance of return values for errors?
My rule of thumb is that if you expect an error to occur more often than 1 in 10,000 times, then use a return value. If you expect the error to be less frequent than 1 in 10,000 times, then use an exception.
Quote:Original post by SiCrane My rule of thumb is that if you expect an error to occur more often than 1 in 10,000 times, then use a return value. If you expect the error to be less frequent than 1 in 10,000 times, then use an exception.
Even if the value has to be returned five times before it's handled? Is this just a performance consideration?
It's a rule of thumb, not the final word on the subject. If you have reasons to modify or ignore it, feel free. For example, if programming for the PS2 you might as well forget that you ever heard the word exception. That being said, a function shouldn't care how many levels up an error it signals propagates before it gets handled.
But, yes, the derivation of this number is based on performance. Roughly speaking, executing a function and checking the return code with an if has one cost, executing a function that uses exceptions for error handling that doesn't throw has another, smaller cost and executing a function that uses exceptions for error handling that does throw has a third cost, greater by orders of magnitude than the other two costs. In MSVC, where I do the majority of my C++ work, the break even point between exceptions and return codes is roughly around 1 in 10,000. The number moves up or down depending on how exactly you decide to measure the relative costs, but 1 in 10,000 seems to be the right order of magnitude. (My gut feeling is that it might be actually closer to 1 in 20,000, but given the difficulty of probability estimation, there doesn't seem much point in trying to develop a more exact number.) gcc Dwarf-2 exception handling seems to also be around the same order of magnitude on platforms I've examined as well.
