- basic non-throwing initialization only constructor
  - a "bool Initialize" method which does what the constructor would have done, but returns false on fail
  - destructor as usual to clean up

Objects with an artificial invalid state are an antipattern in idiomatic c++.

And the destructor has to check for initialization before cleanup.

I'd be very suspicious of any failure avoidance system that relies on "user caution".

Now, true, some of these impose lesser burdens than others. Arguably, RAII imposes the least - but not zero. And if you forget with any resource, for that resource you are vulnerable.

And ultimately it should be possible to enforce that all resources are managed, because ultimately all resource interfaces have to be provided by the language runtime. To a certain extent enforcing user-defined invariants is always a matter of taste, but at the same time a language that makes it easy makes people a lot better at it.

    std::ofstream file("example.txt");
    if (!file.is_open()) return;
    // ofstream will close in destructor.

This is exactly not RAII. You acquired the resource and it might not be initialized. And it has the same problem: it's very easy to pass file around when it's not actually valid.

But full exception safety is obviously much more than just properly catching exceptions. I mean avoiding subtle traps like the ones here: https://herbsutter.com/gotw/_102/

Unless you have a bunch of code that just passes the object around without looking into it (so it won't fail there), and then when the crash finally happens, you have no idea where the invalid object came from.

This is really just another form of the billion dollar mistake, except you have invalid objects instead of null pointers (or in the worst case, you have both).

With an unhandled exception, you always have the context of where and why it happened (assuming you know the reason behind throwing it).

use abort() from stdlib.h

When I first used Qt, I wondered how such a large framework could get along without exceptions. After writing some non-trivial Qt programs, I still noticed that there is really no need for exceptions, except when interfacing non-Qt libraries, where I simply caught and handled the exceptions in a small wrapper.

Finally, I got it: Qt uses the Null-Object pattern (not to be confused with Null values!) consistently, which is really in almost all cases the more elegant solution:

https://en.wikipedia.org/wiki/Null_Object_pattern

This is probably the only sane alternative to exceptions - optional types and result<T, E> types.

> We do not use C++ exceptions.

https://google.github.io/styleguide/cppguide.html#Exceptions

http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or...

The exceptions crash the program. It's helpful and critical to debug the program and to stop it in case of bug/failure.

That said. I never use exceptions per-se. I just happen to get a std::out_of_bound_exception once in a while (for which there is nothing to be done, except crash :D).

Not sure what would happen if exceptions were disabled. Maybe the error handling would be disabled and program would keep running[1]. Maybe the STL would just call abort() instead of throwing an exception[2].

[1] That would be a disaster. Should never disable exception if so.