Re: [Boost-users] Re: Guidelines for effective exception usage

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-08-24 08:15:27

Victor A. Wagner Jr. wrote:
> At Monday 2004-08-23 13:55, you wrote:
>> Jeff Holle <jeff.holle_at_[hidden]> 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.