Exception handling in virtual destructor - c++

Question

I have a two Database class objects allocated on Stack. I inherit this database class in my personal defined class. Now Database class has a function named "Close()" which throws an exception if closing that instance of database fails. Now for client perspective i don't want Client to call close() everytime to close the connection, rather i want to declare a vitrual Desctuctor in Database class which will automatically close the connection when object goes out of scope.
Now problem i am facing is, if i create two DB objects, and now try to delete both and if close succedds for both it's fine, but if close fails for first object it throws an exception, and now second is still allocated (if dynamically allocated member objects), which results in memory leak. How to handle this situation.

Answer 1

you don't throw exception from the destructor what-so-ever!
See : http://www.stroustrup.com/bs_faq2.html#ctor-exceptions
Bjarne quote (can you throw exception from a d.tor):
Not really: You can throw an exception in a destructor, but that exception must not leave the destructor; if a destructor exits by a throw, all kinds of bad things are likely to happen because the basic rules of the standard library and the language itself will be violated. Don't do it.
You might not want to allocate any DB object on the stack anyway, a safe, reusable way is to use Connection Pool :
https://en.wikipedia.org/wiki/Object_pool_pattern
like this, the destruction of each conenction object iswhen the program exist, where you can handle the closing as integral part of the pool, and not in a spread way in some random functions

Answer 2

You probably should have a class for holding one database connection, and another class holding two instances of the first. Since I figure the creation of a database could fail as well, having each connection in its own class (with its own destructor) will handle partial construction / destruction quite nicely.
Besides, if a destructor throws, there is very little you can do (aside from logging the condition). Your application is doomed.

Answer 3

Do not throw exceptions from destructors, bad things happens, use a shutdown() method and call it ouside of destructor. Most C++ stuff is cleaned in destructors, if you throw from within a destructor you literally stop cleaning up things and you would end up having a C++ program in undefined state:
class Database{
std::vector<int> v;
connection c;
public:
~Database(){
c.close(); //ouch throws v don't get deallocated. (neither c)
}
};
may be changed to:
class Database{
std::vector<int> v;
connection c;
public:
~Database(){
// v deallocated here
}
void shutdown(){
c.close();
}
};
main.cpp
int main(){
Database d;
d.shutdown(); //even if d throws, d destructor will be called.
//and as consequence of d destructor also c & v
//destructors are called.
return 0;
}
since you have 2 databases
int main(){
Database d1,d2;
try{
d1.shutdown();
}catch( /** correct exception type*/){
//error handling for 1
}
try{
d2.shutdown();
}catch( /** correct exception type*/){
//error handling for 2
}
//both destructors called
return 0;
}

Answer 4

Chances are that if close fails, there is not good recovery path anyway, you are best off logging the error and then carrying on as if it succeeded. So I would suggest you call close in a try block in you destructor and just logging the error in the corresponding catch block. The destructor can then complete normally.
As #David mentions above, destuctors should never leak exceptions, this is because destructors are called when an exception happens and an exception in an exception causes a crash.

Answer 5

Exceptions should never be thrown in destructor call.
You should not call anything that can cause them there, otherwise, you're crashing your class safety.
You should add a function that checks if database object can be "closed", not an exception. If you imagine that you just can't call function in destructor that may throw exception, you will find solution.
My choice is to do not use destructors to destroy associated objects, if there is a chance that this must not be allowed.
Destructors are intended to free only internal object resources only. You can create a something like resource manager that will store pointers to all objects you need to control. These may be shared pointers. And let this class make your behavior and not objects theirself.