2

This question is inspired by this post: reason for memory leakage in C C++

What are the other kind for problem that can arise because of using exceptions?

I mean what are the problems that we should keep in mind while using exception handling

Community
  • 1
  • 1
ashmish2
  • 2,885
  • 8
  • 40
  • 54
  • 3
    Problems arise not because of using exceptions, but because of handling exceptions improperly. – khachik Dec 15 '10 at 08:48
  • ys i meant that only.. what are the problems that we keep in mind while using exception handling – ashmish2 Dec 15 '10 at 08:52
  • 1
    the problems that will be mentioned below apply to any form of early exit. It just turns out that exceptions create hidden flows in the execution of the code, and therefore hidden "early exit" points. – Matthieu M. Dec 15 '10 at 09:10
  • The question should be: "Why does RAII make exception handling so easy" – Martin York Dec 15 '10 at 10:30

3 Answers3

4

Actually any algorithm can break if an unanticipated exception is thrown.

For example, the algorithms needs to perform two actions sequentially and the second action results in an exception - the first one is not cancelled (unless you take care of this) and the program is in inconsistent state now. In the situation you linked to the inconsistency manifests itself as a memory leak - code intended to deallocate memory but the deallocation code wasn't run because of an exception.

The solution is to expect exceptions and use RAII for managing resources and states consistency. For example if you need to perform two actions you first create a "bracket class" instance on stack and after the second action is done you run a special method on that instance that means that both actions have run successfully. If an exception is thrown the destructor of that class will rollback the first action.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
2

Bjarne Stroustrup has made the chapter on exception safety (The C++ Programming Language, 3rd ed.) available.

Additionally you have to make sure that exceptions interrupting your functions mid-call will be harmless. If you use RAII (the generally recommended approach) to automatically release mutexes, for instance, you could get halfway through an atomic operation (money withdrawn from bank account 1), throw an exception, and leave the system in an inappropriate state (money not yet deposited to bank account 2).

The somewhat classic ScopeGuard article has additional information.

Max Lybbert
  • 19,717
  • 4
  • 46
  • 69
0

Firstly, the memory leakage question you link to isn't related to exception handling per se, it's simply a matter of not handling all the ways in which some code you want to run may be bypassed. It would be equally applicable for return, exit(), a break or if that bypassed some cleanup code etc. - it's just less obvious with exceptions. RAII is the normal way to handle this class of error (though exit() prevents some objects' destructors running).

Re exceptions:

  • they can be left uncaught, resulting in program termination
  • they can be caught in the wrong place, resulting in inappropriate handling and possible unintended behaviour
  • classic boost::shared_ptr<> mistake: f(shared_ptr<int>(new int(2)), g());, where g() may throw, may leak memory
  • exception specifications are generally discredited
Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • exit() causes all memory to be cleaned up, therefore no leaks. The use of exception specifications are discouraged (not discredited). The problem with shared_ptr is not a problem. If you handle an exception in wrong place, it is a bug. Not catching exception should terminate the problem - nothing wrong with that – BЈовић Dec 15 '10 at 08:59
  • 2
    @VJo: Yes, but if your program relied on a destructor side-effect (like writing something on disk) that destructor might not have been run and your program behavior might have been altered. – sharptooth Dec 15 '10 at 09:00
  • 1
    @VJo: there's nothing inherently wrong with exceptions, so I take this question to mean "what might a newbie do that could come back to haunt them". exit() can bypass destructors that release resources such as shared memory segments that outlive the process, as well as preventing flushing of data, orderly disconnects from other systems etc.. shared_ptr problem is a problem, or the boost homepage for shared_ptr wouldn't list it. – Tony Delroy Dec 15 '10 at 09:05
  • @VJo: re exception specifications, consider "Moral #1: Never write an exception specification. Moral #2: Except possibly an empty one, but if I were you I’d avoid even that." from http://www.gotw.ca/publications/mill22.htm. – Tony Delroy Dec 15 '10 at 09:08
  • 1
    The shared_ptr example is a problem - it's legal to evaluate the arguments to `f` in this order: call `new int(2)`, `call g()`, `call shared_ptr constructor`. – JoeG Dec 15 '10 at 09:29
  • @VJo: old point, but from Stroustrup "The exception specifications of C++98 were a compromise design that we would have been better off without. They are now deprecated, so don't use them. They lead to efficiency problems and surprises." http://www.codeguru.com/cpp/misc/article.php/c18357__3/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm – Tony Delroy Jan 12 '11 at 02:40
  • Great. So, we all agree on the rule "do not use exception specifications" :) As for exception calling abort, only a newb would not caught all exceptions in the main() and exit gracefully (return 1 in the catch block). – BЈовић Jan 12 '11 at 08:41