[nikic]

Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time).

E.g. the example with file open + close in the presentation is laughable. Every C++ programmer knows that this is something that should be done with RAII. I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path.

Also one should point out that C++11 has unique_ptr and shared_ptr which in many cases remove the need for the programmer to manage things by himself.

[betterunix]

"I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path."

Unless closing the handle causes an exception to be thrown. Either you never see the exception or your program aborts, and neither one is particularly good if you want to write reliable code.

[ycombobreaker]

"Unless closing the handle causes an exception to be thrown."

That is a straw-man argument. If the underlying file-closing API can throw exceptions, they must be caught from the destructor. If that means that they get ignored, then that is what it will have to be (much the same as most C programs ignore the return call from `printf`). Also in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability.

In any case, provide RAII _safety_ does not intrinsically reduce reliability. If your destructor is executing code which _must_ succeed or be handled at a higher level, then a good developer will not put it in the destructor. No language feature can solve the question of "where should the program stop caring about failure?"

[cliffbean]

> in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability.

Indeed; this is a useful technique. However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a destructor. And that basically means you're not doing RAII anymore.

So yes, RAII is intrinsically incompatible with this kind of reliability.

[ycombobreaker]

> However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a destructor.

Not true at all. `close` and the destructor should be idempotent. In the main path, `close` will get called and failure will propogate upward. In any other failure path, the destructor will attempt to perform the underlying close and allow the stack to unwind without any further interruption.

Of course, anyone can come up with pathological cases where this is not acceptable behavior from a high-reliability sub-component. And in such a situation, RAII may not be the best answer (nor would lexical scoping i.e. constructor/destructor, for that matter!) But in my experience, this approach is just fine for most application-level code.

[betterunix]

...or we could retool exceptions so that destructor exceptions are safe (as long as they are caught). Conditions in Common Lisp, for example:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

[drucken]

Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time).

... and the remaining people realise that use of exceptions in C++,

1. almost always creates a trade-off in performance for strong-exception safety guarantees

2. requires special and strong control of side effects throughout the code base, even when there is minimal benefit

3. increases compile times and resource pressure

4. encourages less knowledgeable developers to inappropriately throw exceptions or make poor attempts to recover from them

5. contain some of the least portable platform semantics and handling.

C++ exceptions contain far greater costs and consequences than many programmers realise. For anything other than testing frameworks, it is debatable that they are worth any benefit at all compared to the alternatives.