Re: Descriptive exceptions
* Stefan Chrobot:
Some time ago I wrote a one-header class implementing Java-like
exception system.
It's generally not a good idea to add too much information to
exceptions. I once wrote a Java interface for logging to the Windows
event log, assuming that 4K or 8K or whatever it was would be "infinite"
for the purposes of converting the exception string from Java's UTF-8,
but as it turned out, those Java exception messages are really sumthing!
All that information has to be assembled and copied, and is in general
just useless garbage; mostly, except for logging at the point of throw,
what one's interested in in the program code is just whether an
exception occurred or not, and when one's interested in the call stack
and so on, one's typically running the program in a debugger.
I don't want to discuss which is better, but AFAIK
there's a bug in the Error class. If, by any reason, memory gets
exhausted during construction of my exception, the program will get
terminated, won't it?
Depends on many things.
If a std::bad_alloc exception is thrown during construction of the
argument to throw, all that happens is that a std::bad_alloc exception
is thrown instead of your exception.
If a std::bad_alloc exception is thrown during copying of one your
exception objects, it may result in a call to std::terminate.
virtual const char* what() const throw()
{
return str.c_str();
}
private:
std::string str;
Instead of this you should simply pass the string to the std::exception
constructor, which /in practice/ may be a lot safer.
However, that's not guaranteed to avoid std::bad_alloc; see <url:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254>.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]