Question: According to the [LLVM Coding Standards](http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions), "LLVM does not use [...] exceptions". However, LLVM does make use of C++'s standard containers, such as `std::vector`.

How is it possible for LLVM to use the standard containers without exceptions? How does it handle a situation in which a container would normally `throw`? For example, what happens if `std::vector::push_back` cannot allocate memory and cannot `throw std::bad_alloc`?

Answer: 
LLVM treats reaching a state which would throw an exception as an immediate crash. If the implementation / compilation settings used enable exceptions, one is thrown unwinds and finds no catch handler and calls `std::terminate`. If the implementation / compilation settings disable exceptions, the implementation must provide some alternative behavior. Most will crash immediately in one way or another.

Developers on LLVM test their code with exactly these settings and are careful to avoid circumstances that could potentially throw.

One circumstance which is impossible to avoid directly is allocation failures. LLVM simply does not support platforms where allocations may fail and the user have to catch `bad_alloc`. If the platform fails to allocate memory at any point, LLVM will crash.

It turns out that the vast majority of non-embedded platforms today use some form of [overcommit](https://www.kernel.org/doc/Documentation/vm/overcommit-accounting). And due to the nature of how LLVM is engineered, we have no particularly useful mechanism available to respond gracefully to a failure to allocate memory. As a consequence, it is considered a fatal and irrecoverable error, and whether we enable exceptions or not, we're going to terminate the process at that point.
The libc++ implementation contains checks on `_LIBCPP_NO_EXCEPTIONS`, which is deduced from the compiler support for exceptions.

If I take a look at the specific implementation for vector, it looks like the condition is asserted instead of throwing an exception. However, I haven't been able to verify this for the `bad_alloc`.

As no documentation exists about the behavior when `-fno-exceptions` is given, I would assume that the application crashes.