1

In wikipedia we read:

Resource Acquisition Is Initialization RAII is a programming idiom used in several object-oriented languages like C++, D, Ada and Vala. The technique was invented by Bjarne Stroustrup to deal with resource allocation and deallocation in C++. In this language, the only code that can be guaranteed to be executed after an exception is thrown are the destructors of objects residing on the stack.

I don't want to be over pedantic, whatever, but I really am not sure how to interpret this. Is this a slip of the tongue or is this correct? Aren't catch handlers guaranteed to be executed at least?

I know about RAII and what it is, I am focused here on this only code that can be guaranteed to be executed (..) are destructors of objects residing on the stack.

4pie0
  • 29,204
  • 9
  • 82
  • 118
  • This quote actually contradicts what was stated in one of the recent answers on SO. According to that answer (lemme find it), if there's no catch handler for the thrown exception, the program is allowed to terminate without unwinding the stack. I.e. the destructors are NOT guaranteed to be executed in that case. – AnT stands with Russia Aug 30 '13 at 15:39
  • If, during stack unwinding, a dtor of an object on the stack throws, no more exception handling happens. `std::terminate()` is called right away. That would certainly prevent a `catch` from being reached. – Angew is no longer proud of SO Aug 30 '13 at 15:40
  • I think AndreyT you meant also this case, however I know this, I am talking about any general code that is guaranteed to be called. – 4pie0 Aug 30 '13 at 15:41
  • 1
    This once again demonstrates that Wikipedia is **not** an authoritative source. – Pete Becker Aug 30 '13 at 15:44
  • While the article is not *technically* correct, I can't, off the top of my head, think of a better way to word it without an elongated explanation that completely distracts from the point of the article. However, the fact that you are asking this question shows that, perhaps, it does need to be reworded (by a better writer than me). – Benjamin Lindley Aug 30 '13 at 15:45
  • It is not the most recent one, but it is about what I meant: http://stackoverflow.com/questions/222175/why-destructor-is-not-called-on-exception – AnT stands with Russia Aug 30 '13 at 15:51
  • **the only code that can be guaranteed to be executed** - this sounds so severely that caught my eye – 4pie0 Aug 30 '13 at 15:51
  • yes, calling terminate because of no handler is known issue – 4pie0 Aug 30 '13 at 15:54
  • 1
    How about this as a replacement for that line? **If an exception is thrown, and proper exception handling is in place, the only code that will be executed for the current scope are the destructors of objects declared in that scope.** – Benjamin Lindley Aug 30 '13 at 15:56
  • for me sounds more suitable/appropriate – 4pie0 Aug 30 '13 at 16:04

2 Answers2

2

Strictly speaking, the quote is already wrong. When an exception is thrown and there's no matching handler for it, terminate can be called without unwinding the stack and calling any destructors. So, the statement that says that "destructors are guaranteed to be executed when an exception is thrown" is wrong.

As for catch handlers themselves, of course, it is only possible to execute a catch handler if the matching catch handler actually exists.

On top of that, even if the handler exists, there are other reasons that can throw a spanner in the works and prematurely terminate the processing of the exception before it reaches the catch handler. For example, it happens when an "unexpected" exception is thrown. If your function exception specification prohibits some specific exception type and an exception of such "prohibited" type attempts to "fly out" of that function, unexpected will be called immediately, instead of transferring control to the handler.

As mentioned in the comments, another typical situation is when new exception is thrown during stack unwinding triggered by a previous exception. This will result in terminate being called.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • so this is right to say that catch is not guaranteed to be called, we may have terminate first because of exception in dctor during stuck unwinding right? I just would like someone to confirm myself – 4pie0 Aug 30 '13 at 15:47
  • @computer: Yes, that's correct. In other words, there are some situations that a thrown exception can encounter on its way to the `catch` handler, which are considered "more-or-less catastrophic failures" by the language. If something like that happens, it is possible that the exception will never reach the handler. – AnT stands with Russia Aug 30 '13 at 15:53
  • "If your function exception specification prohibits some specific exception", you mean when a function throws an exception that is not listed in its dynamic-exception-specifier (i.e., in its throw specifier) right? – 4pie0 Aug 30 '13 at 16:03
0

The only reason why I would say that Wikipedia is correct there is because if the exception causes the entire application to crash and stop execution, then it wouldn't make it down to the "catch" handler. For the most part you can guarantee that the catch clause will be found and executed.

Source: http://msdn.microsoft.com/en-us/library/fk6t46tz.aspx

Mark
  • 418
  • 1
  • 4
  • 13
  • In that case it is **not** guaranteed that stack objects will be destroyed. If no handler is found, the implementation calls `std::terminate()` and it is implementation-defined whether or not the stack is unwound. – Pete Becker Aug 30 '13 at 15:47