항목 8. 예외가 소멸자를 떠나지 못하도록 붙들어 놓자

#include <iostream> #include <vector> using namespace std; class DBConnection { public: //DBConnection 객체를 반환하는 함수. static DBConnection create() { cout << "DBConnection::create()" << endl; DBConnection temp; return temp; } //연결을 닫는다. 연결이 실패하면 예외를 던진다. void close(){ cout << "DBConnection::close()" << endl; } }; class DBConn { public: DBConn(DBConnection temp) { cout << "DBConn() 생성자" << endl; db = temp; } // 데이터베이스 연결이 항상 닫히도록 확실히 챙겨주는 함수 ~DBConn() { cout << "~DBConn() 소멸자" << endl; db.close(); // close()함수에서 에러가 발생하면 문제가 발생한다. } private: DBConnection db; }; int main() { // DBConnection 객체를 생성하고 이것을 DBConn 객체로 넘겨서 관리를 맡긴다. DBConn dbc(DBConnection::create()); return 0; }

 위와 같이 데이터베이스를 연결하는 클래스가 있다고 가정해 봅시다. 보시다시피, 사용자가 DBConnection 객체에 대해 close를 직접 호출해야 하는 설계임을 알 수 있습니다. 이 close 호출만 성공하면 아무 문제될 것이 없는 코드 인데,  여기서 close 호출 시 예외가 발생했다고 가정해 보면 어떨까요? DBConn의 소멸자는 분명히 이 예외를 나가도록 내버려 둘 것입니다. 이게 바로 문제점입니다. 예외를 던지는 소멸자는 문제점을 가지고 있습니다. 그리고 이 문제를 피하는 방법은 두가지 정도로 나뉩니다. 

문제해결 하나!

 : close에서 예외가 발생하면 프로그램을 바로 끝낸다. 대개 abort를 호출해준다.

DBConn::~DBConn() { cout << "~DBConn() 소멸자" << endl; try { db.close(); } catch(...) { // close 호출이 실패했다는 로그를 작성. abort(); } }

 객체 소멸이 진행 되다가 에러가 발생한 후에 프로그램 실행을 계속할 수 없는 상황에서는 괜찮을 선택일 것입니다. 소멸자에서 생긴 예외를 그대로 나가도록 했다가는 정의되지 않은 동작에까지 이를 수 있다면, 그런 불상사를 막아버리는 방법도 괜찮은 방법이겠죠?

문제해결 둘!

 : close를 호출한 곳에서 일어난 예외를 삼켜 버린다.

DBConn::~DBConn() { cout << "~DBConn() 소멸자" << endl; try { db.close(); } catch(...) { // close 호출이 실패했다믄 로그를 작성. } }

 이 방법은 중요한 정보(무엇이 잘못됐는지)가 묻혀 버리기 때문에 대부분의 경우에는 좋은 방법은 아니지만,  때에 따라서는 불완전한 프로그램 종료 혹은 미정의 동작으로 인해 입는 위험을 감수하는 것보다 그냥 예외를 먹어버리는게 나을 수도 있다는 것입니다. 단 이 방법이 제대로 빛을 보려면, 발생한 예외를 그냥 무시한 뒤라도 프로그램이 신뢰성 있게 실행을 지속할 수 있어야 합니다.

 하지만 위 둘의 방법은 각자의 문제점을 가지고 있습니다. 중요한것은 close가 최초로 예외를 던지게 된 요인에 대해 프로글매이 어떤 조치를 취할 수 있는가인데, 이런 부분에 대한 대책이 없기 때문입니다. 그럼 더 나은 방법은 뭐가 있는지 살펴 보도록 하죠. 

새로운 문제 해결

 : 그렇다면 DBConn 인터페이스를 잘 설계해서, 발생할 소지가 있는 문제에 대처할 기회를 사용자가 가질 수 있도록 하면 어떨까요? 예를 들어 DBConn에서 Close 함수를 직접 제공하게 하면 이 함수의 실행 중에 발생하는 예외를 사용자가 직접 처리할 수 있을 것입니다.  DBConnection이 닫혔는지의 여부를 유지했다가, 닫히지 않았으면 DBConn의 소멸자에서 닫을 수도 있을 것이고, 이렇게 하면 데이터베이스 연결이 누출 되지 않습니다. 하지만 소멸자에서 호출하는 close마저 실패한다면 이야기가 달라지겠지만 말이죠. 

#include <iostream> #include <vector> using namespace std; class DBConnection { public: // DBConnection 객체를 반환하는 함수. static DBConnection create() { cout << "DBConnection::create()" << endl; DBConnection temp; return temp; } // 연결을 닫는다. 연결이 실패하면 예외를 던진다. void close(){ cout << "DBConnection::close()" << endl; } }; class DBConn { public: DBConn(DBConnection temp) { cout << "DBConn() 생성자" << endl; db = temp; } void close() { cout << "close() 함수 호출" << endl; db.close(); closed = true; } ~DBConn() { cout << "~DBConn() 소멸자" << endl; if (!closed) { try { cout << "try::close() 함수 호출" << endl; db.close(); // 사용자가 연결을 안 닫았으면 여기서 닫는다. } catch(...) { // close 호출이 실패했다는 로그를 작성. } } } private: DBConnection db; bool closed; }; int main() { DBConn dbc(DBConnection::create()); dbc.close(); return 0; }

 여기에서 어떤 동작이 예외를 일으키면서 실패할 가능성이 있고 또 그 예외를 처리해야 할 필요가 있다면, 그 예외는 소멸자가 아닌 다른 함수에서 비롯된 것이어야 한다는 것이 포인트 입니다. 왜냐하면 예외를 일으키는 소멸자는 시한폭탄과 마찬가지라서 프로그램의 불완전 종료 혹은 미정의 동작의 위험을 내포 하고 있기 때문입니다. 

 위의 예제를 보면 사용자가 호출할 수 있는 close 함수를 둬서, 사용자에게 에러를 처리할 수 있는 기회를 주고 있습니다. 이것마저 없다면 사용자는 예외에 대처할 기회를 포착하지 못하게 될테죠. 사용자가 이 기회를 무시 했다고 해도 DBConn이 close 함수를 호출해 줄것이므로 문제는 없습니다. 

 * 소멸자에서는 예외가 빠져나가면 안됩니다. 만약 소멸자 안에서 호출된 함수가 예외를 던질 가능성이 있다면, 어떤 예외이든지 소멸자에서 모두 받아낸 후에 삼켜 버리든지 프로그램을 끝내든지 해야 합니다. 

 * 어떤 클래스의 연산이 진행되다가 던진 예외에 대해 사용자가 반응해야 할 필요가 있다면, 해당 연산을 제공하는 함수는 반드시 보통의 함수(즉, 소멸자가 아닌 함수)이어야 합니다.