On Sep 26, 1:24 am, "Bo Persson" <b...@gmb.dk> wrote:
tf wrote:
An awkward situation with exception handling occurred to me this
morning.
I frequently see (and I'll admit to writing it myself sometimes)
error detection code which does something along these lines:
if(badness) {
std::ostringstream err;
err << "Badness " << errcode << " has occurred while frobbing"
<< " nitzes. blah blah blah";
throw SomeException(err.str().c_str());
}
or just using snprintf:
if(badness) {
char errc[1024];
snprintf(errc, 1024, "badness %d occurred ...", errcode);
throw SomeException(errc);
}
Yet, of course, by the time we get to a:
catch(const SomeException& se) { ... }
clause somewhere up the call stack, the above stack has unwound.
In the first case, the std::string from err.str() has had its
destructor run, so our saved pointer is bogus; in the latter,
there's no destructor for char* of course but the 'errc' array is
"gone".
Why don't you just create a new exception BadnessOccurred, dervied
from SomeException, and carrying the errcode? Its what() member can
produce the message, if and when it is called.
if (badness)
throw BadnessOccurred(errcode);
The problem is the signature of std::exception::what():
virtual const char* what() const throw();
A derived class overriding what() has to:
1) return a pointer to the message string
2) without modifying the exception's state
3) and without throwing anything
I don't know how to dynamically construct a message given these
constraints:
1) suggests using a member string or char array as a formatting
buffer.
2) suggests a mutable member variable formatting buffer
3) makes it impossible to dynamically allocate this buffer
What am I missing?
yourself. That might make it possible to allocate a big enough buffer,
short string optimization. Possibly as a mutable member.
1024 bytes is always enough, and 2) the stack is big enough for that.
[ comp.lang.c++.moderated. First time posters: Do this! ]