HI,

Do anyone have scenrio where destructor throws execption which will
lead to memory leak..Does this make sense..

Cheers up..

Radde wrote:[color=blue]
> HI,
>
> Do anyone have scenrio where destructor throws execption which will
> lead to memory leak..Does this make sense..
>
> Cheers up..[/color]
Hopefully not. A destructor should never throw.

/Peter

Radde wrote:[color=blue]
> HI,
>
> Do anyone have scenrio where destructor throws execption which will
> lead to memory leak..Does this make sense..
>
> Cheers up..[/color]

http://www.parashift.com/c++-faq-lit....html#faq-17.3

Destructors must NOT throw exceptions. More precisely, never allow
exceptions to leave destructors. It can lead to memory leaks. Consider
the following code...

template <typename Iter>
void destroy(Iter begin, Iter end)
{
while(begin != end)
{
// destruct object (*begin)
++begin;
}
}

If (*begin) is of type T, and in the loop, the first destructor throws,
then the function will exit and the other objects will never be
destroyed. This was just a crude example to show that destructors that
throw are bad and can cause leaks.

Regards,
Srini

Srini wrote:[color=blue]
>
> If (*begin) is of type T, and in the loop, the first destructor throws,
> then the function will exit and the other objects will never be
> destroyed. This was just a crude example to show that destructors that
> throw are bad and can cause leaks.
>[/color]

That's one interperation. Another one is that the code itself doesn't
properly protect against exceptions.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

> That's one interperation. Another one is that the code itself doesn't[color=blue]
> properly protect against exceptions.[/color]

Yeah - but I don't think the function can be made strongly exception
safe is T's destructor throws. Am I wrong?

Srini

Srini wrote:[color=blue][color=green]
>>That's one interperation. Another one is that the code itself doesn't
>>properly protect against exceptions.[/color]
>
>
> Yeah - but I don't think the function can be made strongly exception
> safe is T's destructor throws. Am I wrong?
>[/color]

I have no idea. You haven't provided a specification for the function.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

* Pete Becker[color=blue]
> I have no idea. You haven't provided a specification for the function.[/color]

I had the things read in GotW in mind. There the listed guidelines are,


1) Even in presence of exceptions, there must be no resource leak

2) If an operation terminates due to an exception, the program state
must remain unchanged (commit or rollback semantics)

Is an exception specification necessary to guarantee the above
exception-safety requirements?

Thanks and Regards,
Srini

Srini wrote:[color=blue]
> * Pete Becker
>[color=green]
>>I have no idea. You haven't provided a specification for the function.[/color]
>
>
> I had the things read in GotW in mind. There the listed guidelines are,
>
>
> 1) Even in presence of exceptions, there must be no resource leak
>
> 2) If an operation terminates due to an exception, the program state
> must remain unchanged (commit or rollback semantics)
>[/color]

Those are guidelines, not rules. They may or may not apply to a
particular function.
[color=blue]
> Is an exception specification necessary to guarantee the above
> exception-safety requirements?
>[/color]

When I said "specification" above I was not referring to an exception
specification, but to a specification of what the function is supposed
to do.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Forget memory leaks, there is another really important reason that
destructors should never ever ever throw. Consider the following:

#include <iostream>
class some_exception {};
class some_other_exception {};
class naughty_class
{
public:
virtual ~naughty_class() {
throw some_exception();
}
/* ... */
};

int main()
{
try {
naughty_class c;
throw some_other_exception();
}
catch(...) {
std::cerr << "Error" << std::endl;
}
}

This program will terminate and the catch block will never be reached:
1. c is created
2. some_other_exception is thrown
3. c's destructor is called
4. the destructor throws an exception. There is already an exception
being thrown and it isn't possible to throw two exceptions at once.
5. the abort() function is called and the program terminates

I heartily recommend that you read Herb Shutter's "Exceptional C++". It
has loads more on throwing destructors and loads of other exception
safety issues.

andy skirrow wrote:[color=blue]
> Forget memory leaks, there is another really important reason that
> destructors should never ever ever throw. Consider the following:
>[/color]

Consider the following:

struct throws
{
~throws() { throw "thrown" }
};

struct doesntthrow
{
doesntthrow() : data(new throws) {}
~doesntthrow()
{
try
{
delete data;
}
catch(...) {}
}
private:
throws *data;
};

int main()
{
try
{
throws t;
throw some_other_exception();
}
catch(...)
{
std::cout << "Error\n";
}
return 0;
}

Be careful not to elevate guidelines into absolute rules. Throwing
exceptions in destructors isn't always bad. Just usually.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Destructors gets called as part of stack unwinding (an Exception is
already thrown).
Throwing an exception in destructor may lead to infinite recursion in
such case.

Cheers
Venkat

venkat.puvvada@gmail.com wrote:[color=blue]
> Destructors gets called as part of stack unwinding (an Exception is
> already thrown).
> Throwing an exception in destructor may lead to infinite recursion in
> such case.
>
> Cheers
> Venkat[/color]


Nope, if two exceptions are thrown at the same time, I think the
standard behaviour is to abort().

-shez-

Shezan Baig wrote:[color=blue]
> venkat.puvvada@gmail.com wrote:
>[color=green]
>>Destructors gets called as part of stack unwinding (an Exception is
>>already thrown).
>>Throwing an exception in destructor may lead to infinite recursion in
>>such case.
>>
>>Cheers
>>Venkat[/color]
>
>
>
> Nope, if two exceptions are thrown at the same time, I think the
> standard behaviour is to abort().
>
> -shez-
>[/color]
Nearly.
terminate() is called. By default, this calles abort(), but you can
register a function to be called in such case.

Gabriel