Exception safety -- once again
Oncaphillis
As far as I understand exception safety
forbids to do anything within a exceptions
constructor which might itself throw
an exception.
But is it o.k to do such things when preparing
an exception to be thrown ?
like:
<snip>
foo() thow(std::exception) {
int c;
if((c=bar())!=0) {
std::stringstream ss;
ss << "bar failed with code=" << c << ";"; // might throw
throw std::excetion(ss.str().c_str());
}
}
</snip>
I know that many people don't like "verbose"
exceptions and would recommend using
a static const char * here, but I think
they could be a benefit.
Thanks you
O.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
aman.c++
> Hi,
>
> As far as I understand exception safety
> forbids to do anything within a exceptions
> constructor which might itself throw
> an exception.
>
> But is it o.k to do such things when preparing
> an exception to be thrown ?
>
> like:
>
> <snip>
> foo() thow(std::exception) {
> int c;
>
> if((c=bar())!=0) {
> std::stringstream ss;
> ss << "bar failed with code=" << c << ";"; // might throw
> throw std::excetion(ss.str().c_str());
> }}
>
> </snip>
AFAIK, the std::exception(const char*) is NOT PORTABLE (non-standard).
The constructor std::exception(const char * const &message) is a
Microsoft extension to the standard C++ library.
regards,
Aman Angrish.
Eugene Gershnik
> Hi,
>
> As far as I understand exception safety
> forbids to do anything within a exceptions
> constructor which might itself throw
> an exception.
There are two distinct cases here. First is when the "inner" exception
is different from the "outer" one. The worst that can happen in this
scenario is that another exception will be thrown instead of the one
you originally wanted. This would result in another problem to be
handled (reported/fixed/ignored) by the upper-level code. This
secondary problem is not less real than the primary one, so why
shouldn't it be treated first? If your code is exception-safe (either
weakly or strongly) it still stays safe.
The second scenario is if the "inner" exception is the same as the
"outer" one. This can easily lead to an infinite recursion and so has
to be avoided or dealt with specifically.
In particular you need to be really careful when reporting out-of-
memory-like conditions since realistically the operations you perform
when constructing an exception often throw only when you are out of
memory.
> But is it o.k to do such things when preparing
> an exception to be thrown ?
>
> like:
>
> <snip>
> foo() thow(std::exception) {
> int c;
>
> if((c=bar())!=0) {
> std::stringstream ss;
> ss << "bar failed with code=" << c << ";"; // might throw
> throw std::excetion(ss.str().c_str());
> }}
>
> </snip>
Yes, why not? As long as the line marked "might throw" doesn't call
foo() directly or indirectly you are perfectly safe.
> I know that many people don't like "verbose"
> exceptions and would recommend using
> a static const char * here, but I think
> they could be a benefit.
I love "verbose" exceptions. Since neither standard C++ nor popular
implementations give us anything approaching the stack traces and
chained exceptions of VM-based languages, having a verbose exception
that tells as much as possible about what went wrong is the only way
to diagnose problems in deployed code.
--
Eugene
Oncaphillis
>> <snip>
>> foo() thow(std::exception) {
>> int c;
>>
>> if((c=bar())!=0) {
>> std::stringstream ss;
>> ss << "bar failed with code=" << c << ";"; // might throw
>> throw std::excetion(ss.str().c_str());
>> }}
>>
>> </snip>
>
> AFAIK, the std::exception(const char*) is NOT PORTABLE (non-standard).
> The constructor std::exception(const char * const &message) is a
> Microsoft extension to the standard C++ library.
>
> regards,
> Aman Angrish.
>
Oh !! I never used the MS library. That code is just typed in
as an example. I never user std::exception directly but
the subclasses anyway. Was meant as an example.
Thanks for the info
O.
David Abrahams
on Thu Jul 24 2008, Oncaphillis <oncaphillis-AT-snafu.de> wrote:
> Hi,
>
> As far as I understand exception safety
> forbids to do anything within a exceptions
> constructor which might itself throw
> an exception.
Not really. You will end up reporting the second error condition
instead of the original one, but that's usually not very harmful. If
you're low on memory and low on disk and one runs out while trying to
report about the other, who cares which one you find out about first?
> But is it o.k to do such things when preparing
> an exception to be thrown ?
Construction is one of the things you do when preparing to throw ;-)
> <snip>
> foo() thow(std::exception) {
> int c;
>
> if((c=bar())!=0) {
> std::stringstream ss;
> ss << "bar failed with code=" << c << ";"; // might throw
> throw std::excetion(ss.str().c_str());
> }
> }
> </snip>
The constructor to std::exception doesn't take any arguments.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com