std exceptions inviting unsafe usage?

Question

It is recommended that you always throw something derived from std::exception and there are a few predefines specialisations such as std::runtime_error

std::exception's interface is given in terms of non-throwing accessors. Great. Now look at the constructor for std::runtime_error

class runtime_error : public exception {
public:
  explicit runtime_error (const string &);
};

So if I do this

try {
    foo ();
}
catch (...) {
    throw std :: runtime_error ("bang");
}

it's entirely possible that foo threw because it's out of memory, in which case constructing the string argument to runtime_error can also throw. This would be a throw-expression which itself also throws: won't this will call std::terminate?

Doesn't this mean we should always do this instead:

namespace {
    const std :: string BANG ("bang");
}

...

try {
    foo ();
}
catch (...) {
    throw std :: runtime_error (BANG);
}

BUT WAIT this won't work either, will it? Because runtime_error is going to copy its argument, which may also throw...

...so doesn't this mean that there is no safe way to use the standard specialisations of std::exception, and that you should always roll your own string class whose constructor only fails without throwing?

Or is there some trick I'm missing?

Answer 1

I think your main problem is that you are doing catch(...) and translating to a std::runtime_error thereby losing all type information from the original exception. You should just rethrow with throw().

Practically, if you are short of memory you are likely have a bad_alloc exception thrown at some point and there's not a lot else you can - or should - do. If you want to throw an exception for a reason other than an allocation failed then you are not likely to have a problem constructing a sensible exception object with meaningful contextual information. If you hit a memory issue while formatting your exception object there's not a lot you can do other than propagate the memory error.

You are right that there is a potential problem if you construct a new string object to construct an exception, but if you want to format a message with context this can't be avoided in general. Note that the standard exception objects all have a const char* constructor (as of last week) so if you have a const char* that you want to use you don't have to construct a new std::string object.

std::runtime_error must copy it's argument, but not necessarily as a new string object. There could be an area of statically allocated memory which it can the contents of its argument to. It only has to fulfil the what() requirements which only requires returning a const char *, it doesn't have to store a std::string object.

Answer 2

This would be a throw-expression which itself also throws: won't this will call std::terminate?

No, it wouldn't. It would just throw the exception about insufficient memory. The control will not reach the outer throw part.

BUT WAIT this won't work either, will it? Because runtime_error is going to copy its argument, which may also throw...

Exception classes with a throwing copy-constructors are as evil as throwing destructors. Nothing that can really be done about it.