no-throw exception guarantee and stack overflow

Question

There are several special functions which usually guarantee not to throw excpetions, e.g.:

• Destructors
• swap method

Consider the following swap implementation, as stated in this answer:

friend void swap(dumb_array& first, dumb_array& second)
{
    using std::swap; 

    swap(first.mSize, second.mSize);  
    swap(first.mArray, second.mArray);  // What if stack overlow occurs here?
}

It uses two swap functions - for integer and for pointer. What if the second function will cause stack overflow? Objects will become corrupted. I guess it is not an std::exception, it is some kind of system exception, like Win32-exception. But now we cannot guarantee no-throwing, since we're calling a function.

But all authoritative sources just use swap like it's ok, no exceptions will ever be thrown here. Why?

Answer 1

In general you cannot handle running out of stack. The standard doesn't say what happens if you run out of stack, neither does it talk about what the stack is, how much is available, etc. OSes may let you control it at the time the executable is built or when it is run, all of which is fairly irrelevant if you're writing library code, since you have no control of how much stack the process has, or how much has already been used before the user calls into your library.

You can assume that stack overflow results in the OS doing something external to your program. A very simple OS might just let it go weird (undefined behavior), a serious OS might blow the process away, or if you're really unlucky it throws some implementation-defined exception. I actually don't know whether Windows offers an SEH exception for stack overflow, but if it does then it's probably best not to enable it.

If you're concerned, you can mark your swap function as noexcept. Then in a conforming implementation, any exception that tries to leave the function will cause the program to terminate(). That is to say, it fulfils the noexcept contract at the cost of taking out your program.

Answer 2

What if the second function will cause stack overflow?

Then your program is in an unrecoverable faulted state, and there is no practical way to handle the situation. Hopefully, the overflow has already caused a segmenation fault and terminated the program.

But now we cannot guarantee no-throwing

I've never encountered an implementation that would throw an exception in that state, and I'd be rather scared if it did.

But all authoritative sources just use swap like it's ok, no exceptions will ever be thrown here. Why?

The authoritative sources I've read (like this one, for example) don't "just use it like it's OK"; they say that if you have (for example) a non-throwing swap function, and a non-throwing destructor, then you can provide exception-safety guarantees from functions that use them.

It's useful to categorise functions according to their exception guarantees:

• Basic: exceptions leave everything in a valid but unspecified state
• Strong: exceptions leave the state unchanged
• No-throw: no exceptions will be thrown.

Than a common approach to providing the "strong" guarantee is:

• do the work that might throw on a temporary copy of the state
• swap that copy with the live state (requiring a non-throwing swap operation)
• destroy the old state (requiring a non-throwing destructor)

If you don't have a no-throw guarantee from those operations, then it's more difficult, and perhaps impossible, to provide a strong guarantee.