Does Noexcept allocate memory dynamically? No.

Does Noexcept require RTTI? No.

When using exception handling, there can be multiple active exception objects in each thread. Does Noexcept support multiple active errors? Yes, the current error object can be captured using try_ , at which point the calling thread is left without a current error. However, it is up to the user to call try_ : the code below is ill-formed, assuming that both function calls may fail — that is, return using throw_(my_error()) , for some user-defined type my_error : auto r1=f1(); auto r2=f2(); The correct code would ensure that at the time f2() is called there is no current error for the calling thread. This could be achieved either by checking the return value of f1() (assuming r1 converts to bool to indicate success or failure): if( auto r1=f1() ) { auto r2=f2(); //okay for f2 to fail (f1 didn't) .... } else { return r1.throw_(); //let the caller deal with failures } or by capturing f1 failures using try_ : auto r1=try_(f1()); //capture possible f1 failures auto r2=f2(); //okay, even if both f1 and f2 fail The above is not unlike when using exception handling: if you want to call f2 even if f1 throws, you’d have to call f1 from within a try / catch . (Nothrow asserts on !has_current_error() at the time an error object is passed to throw_ ).

Does this mean that I should always use try_ ? No, only use try_ if you want to handle errors (see catch_ ). In error-neutral contexts, in case of errors simply return throw_() without argument: if( auto r=f() ) { //Success -- use r } else { return r.throw_(); //Something went wrong } The above assumes that r converts to bool to indicate success or failure (there are many types than can be used this way). If that is not the case, ideally you would still be able to inspect the returned value to detect failures. If that is also not possible, use has_current_error() .

What happens if I forget to check for errors? Then you’d be using a bad value. For example, if a function returns a shared_ptr<T> and you forget to check for success, attempting to dereference it leads to undefined behavior (segfault). If control is entering a scope where exception handling is enabled, you can convert Noexcept errors to exceptions by try_(f()).get() , which throws on error. That said, it is sometimes possible to get away with not checking for errors in error-neutral contexts, see Programming techniques and guidelines.

What happens if try_ is called without any error being present? That is fine, in this case the value passed to try_ will simply be moved into the returned result object, where it can be accessed using the get() member function.

Has Noexcept been benchmarked? Not yet, but performance is an important design goal in Noexcept and I welcome any data or analysis contributions. That said, except in functions that handle errors (see try_ ), Noexcept has no effect on the speed of passing return values up the call chain.

Doesn’t Noexcept make it too easy to forget to check for errors? For example, if a function that may fail returns a type without explicit empty state (like int ), there is nothing to protect the user from ignoring errors by mistake! Noexcept does protect the user from this type of mistakes, but it can’t do it on the spot; see the No error gets ignored guarantee. If this does not suffice, don’t write functions that return int to indicate success or failure. However, consider that wrapping the int in a user-defined type adds complexity which may or may not be appropriate.