Boost logo

Boost Users :

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.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at