What a weird claim. Not only do you not need exceptions to use the C++ standard library, but you can (or at least used to be able to) compile C++ code without support for exceptions.

Also, exceptions are not just a fancy goto, at least in C++. They're a fancy longjmp. Goto doesn't unwind the stack.

Edit

Wait wait wait it appears I am wrong about this; the STL we used could be configured not to use exceptions but wow, that sucks, you need them for the standard library.

You actually need exceptions anywhere you do new, unless you exclusively use new(std::nothrow) (hint: you don’t). On top of that the STL may throw exceptions such as std::out_of_range as I responded in another comment. And again, you have to review all your libraries to make sure they don’t throw.

Exceptions are a fancy goto, longjmp is more accurate if you will, but it is my understanding that longjmp will not call all the appropriate destructors, it will just restore the environment which can lead to resources and memory leaks, from the standard:

If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to longjmp(jbuf, val) at the throw point that transfers control to the same (destination) point has undefined behavior.

Some compilers do add the appropriate clean up code to make longjmp cooperative to that aspect, so I might be just nitpicking a little bit here.

What I meant by "fancy goto" is that basically exceptions break the flow and can make the code much, much harder to review and making, solid and reliable code with exceptions is much, much harder than you might think (in C++), Raymond explained it better than me: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

Exceptions aren’t really like “goto”—they’re dynamically bound, dynamically typed, nonlocal “return” statements. Which incidentally is a useless mechanism for error handling unless you have some kind of destruction semantics, which is mentioned in the article. Anyway, given the choice between exceptions and return values for error handling, I go for return values that the compiler can force me to check.

STL "containers" and "streams" that need exceptions are pretty useless for any sort of critical code IMHO. STL "algorithms", on the other hand, are pretty useful and work with exceptions disabled just fine.

This, of course, depends on your definition of "critical code". I, for one, don't see how anything critical can rely on the single memory allocator that came bundled with the compiler.

If this is FUD, please downvote me into grayness, but I remember an article - or maybe even a book - proving that exception-safety in C++ was impossible. I remember nothing else about this; it was probably around 1999-2000.

Am I completely making that up? Or did we discover ways around the "impossible" part? I haven't coded in C++ since, uh, gcc 2.97 or so.

It is flatly untrue that you cannot use the C++ STL if you don't use exceptions. std::nothrow exists for exactly that reason.

I'm afraid you might be confusing a parameter supplied to the memory allocator (e.g. nothrow) and the throwing specifications of the STL.

Example: some containers throw std::out_of_range if you access a non-existing element and this has nothing to do with std::nothrow.

The only core thing I can think of is “std::bad_cast” with “dynamic_cast”, but I’ve never run into that in practice. “std::out_of_range” only happens when you’re using checked member functions that take indices—which I never do, preferring iterators. However, “std::length_error” can theoretically happen, and nobody checks for it, so there is at least one point of failure.

The libcxx stl uses a #define to for exception support or not. When exceptions are disabled, they assert() instead.