RE: [Boost-users] Re: Guidelines for effective exception usage
Peter Dimov
Ben Hutchings wrote:
Peter Dimov
wrote: Victor A. Wagner Jr. wrote:
OK, blunt point. the standard is (insert favorite expletive or "in error") if it allows use of std::runtime_error to terminate the program due to low memory situations (run out of memory (due to copying) during stack unwinding).
It does not allow such a thing.
This is an known and unresolved issue: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254
"The copy constructors of all exception-derived classes already have a no throw spec. Reference 18.6.1, 19.1 and 15.4/13."
"As they stand, the copy constructors might fail via a call to unexpected. I think what is intended here is that the copy constructors can't fail." (Is it really necessary for us to quote the referenced text at each other? This is silly.)
Ben Hutchings wrote:
Peter Dimov
wrote: Ben Hutchings wrote:
Peter Dimov
wrote: Victor A. Wagner Jr. wrote:
OK, blunt point. the standard is (insert favorite expletive or "in error") if it allows use of std::runtime_error to terminate the program due to low memory situations (run out of memory (due to copying) during stack unwinding).
It does not allow such a thing.
This is an known and unresolved issue: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254
"The copy constructors of all exception-derived classes already have a no throw spec. Reference 18.6.1, 19.1 and 15.4/13."
"As they stand, the copy constructors might fail via a call to unexpected. I think what is intended here is that the copy constructors can't fail."
(Is it really necessary for us to quote the referenced text at each other? This is silly.)
Yep. The difference is that the excerpts I quote are correct. ;-) Whenever throw() is used in the standard, it is intended to mean "the function does not throw", not "the function may arbitrarily call unexpected() and abort the program." Of course we all know that throw() actually means the latter, which makes it rather useless as both a documentation tool and a static nothrow checker tool; nevertheless, in the standard signatures, it is supposed to mean the former. Or so Dave says, and he wrote that portion, so he must know. ;-)
"Peter Dimov"
Ben Hutchings wrote:
Peter Dimov
wrote: Ben Hutchings wrote:
Peter Dimov
wrote: Victor A. Wagner Jr. wrote:
OK, blunt point. the standard is (insert favorite expletive or "in error") if it allows use of std::runtime_error to terminate the program due to low memory situations (run out of memory (due to copying) during stack unwinding).
It does not allow such a thing.
This is an known and unresolved issue: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254
"The copy constructors of all exception-derived classes already have a no throw spec. Reference 18.6.1, 19.1 and 15.4/13."
"As they stand, the copy constructors might fail via a call to unexpected. I think what is intended here is that the copy constructors can't fail."
(Is it really necessary for us to quote the referenced text at each other? This is silly.)
Yep. The difference is that the excerpts I quote are correct. ;-)
Whenever throw() is used in the standard, it is intended to mean "the function does not throw", not "the function may arbitrarily call unexpected() and abort the program."
Of course we all know that throw() actually means the latter, which makes it rather useless as both a documentation tool and a static nothrow checker tool; nevertheless, in the standard signatures, it is supposed to mean the former. Or so Dave says, and he wrote that portion, so he must know. ;-)
Actually I didn't write that portion, but Peter's right about everything else. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (3)
-
Ben Hutchings
-
David Abrahams
-
Peter Dimov