Victor A. Wagner Jr. wrote:
At Monday 2004-08-23 13:55, you wrote:
Jeff Holle <jeff.holle@verizon.net> writes:
My two cents of the referenced html page.
Not placing attributes like string into an exception class only makes sense if the exception being thrown has something to do with a memory starvation situation.
For a lot of exception types that I can think of this is not the case. As an example of this std::runtime_error often has a string attribute and this is perfectly fine.
No it is not. Even if you aren't throwing due to memory starvation, you could run out of memory during unwinding, when the exception is copied. That leads you directly to terminate(). Do not pass Go; do not collect $200.
why would unwinding copy the exception?
The question isn't really about what happens in practice (where std::string members usually "work fine", although some implementations do use a proper reference-counted immutable string for std::runtime_error). It's mostly about "principles". Consider a hypothetical language (or tool) that can statically enforce throw() specifications. In such a language, you wouldn't be able to throw a type whose copy constructor is not marked throw(). Since std::string's copy constructor can throw, it can't be a member of a throwable class.