위의 DBConnection 객체에 대해 사용자가 cloase를 직접 호출해야 하는 설계이다. 사용자의 망각을 사전에 차단하는 좋은 방법이라면 DBConnection에 대한 자원관리 클래스를 만들어서 그 클래스의 소멸자에서 close를 호출하게 만드는 것이다.
위의 두 클래스를 활용하여 다음과 같은 프로그래밍이 가능해진다.
close 호출만 일사천리로 성공하면 아무 문제될 것이 없는 코드 이지만 만약 close 호출햇는데 여기서 예외가 발생했다고 가정하면 DBConn의 소멸자는 분명히 이 예외를 전파할 것이다.
어떤 동작이 예외를 일으키면서 실패할 가능성이 있고 또 그 예외를 처리해야 할 필요가 있다면, 그 예외는 소멸자가 아닌 다른 함수에서 비롯된 것이어야 한다는 것이 포인트 이다.
이것만은 잊지 말자!
- 소멸자에서는 예외가 빠져나가면 안된다. 만약 소멸자 안에서 호출된 함수가 예외를 던질 가능성이 있다면, 어떤 예외든지 소멸자에서 모두 받아낸 후에 삼켜버리든지 프로그램을 끝내든지 해야 한다.,
- 어떤 클래스의 연산이 진행되다가 던진 예외에 대해 사용자가 반응해야 할 필요가 있다면, 해당 연산을 제공하는 함수는 반드시 보통의 함수),즉 소멸자가 아닌 함수)이어야 한다.
관련 링크
http://ikpil.tistory.com/409
http://ikpil.tistory.com/365
http://redinlife.egloos.com/1627105
http://ilu8318.egloos.com/1705005
http://flashcafe.org/bbs/board.php?bo_table=programming_study&wr_id=83
이올린에 북마크하기
이올린에 추천하기'Ψ Study > Δ Effective C++ 3판' 카테고리의 다른 글
| 항목 12. 객체의 모든 부분을 빠짐없이 복사하자. (0) | 2009/02/17 |
|---|---|
| 항목 11. operator=에서는 자기대입에 대한 처리가 빠지지 않도록 하자 (0) | 2009/02/17 |
| 항목 10. 대입 연산자는 *this 참조자를 반환하게 하자 (0) | 2009/02/15 |
| 항목 9. 객체 생성 및 소멸 과정 중에는 절대로 가상 함수를 호출하지 말자. (0) | 2009/02/15 |
| 항목 8. 예외가 소멸자를 떠나지 못하도록 붙들여 놓자. (0) | 2008/07/10 |
| 항목 7. 다형성을가진 기본 클래스에서는 소멸자를 반드시 가상 소멸자로 선언하자. (0) | 2008/07/01 |
| 항목 6. 컴파일러가 만들어낸 함수가 필요 없으면 확실히 이들의 사용을 금해 버리자. (0) | 2008/06/27 |
| 항목 5. C++가 은근슬쩍 만들어 호출해 버리는 함수들에 촉각을 세우자 (0) | 2008/06/27 |
| 항목 4. 객체를 사용하기 전에 반드시 그 객체를 초기화하자. (0) | 2008/06/10 |
| 항목 3. 낌새만 보이면 const를 들이대 보자! (0) | 2008/06/10 |
| 항목 2. #define을 쓰려거든 const, enum, inline을 떠올리자. (0) | 2008/05/29 |
트랙백 주소 : http://deviak.com/trackback/2690090
-
Subject : 항목 8: 예외가 소멸자를 떠나지 못하도록 붙들어 놓자.
Tracked from 이름없는 블로그 2008/07/12 02:06 삭제이유 1. 메모리 릭 또는 프로그램 강제 종료를 일으킬수 있기 때문이다. 주의점 1. 관련 링크를 꼭 보도록 참조 1. 예외가 일어날 가능성이 있는 코드는 소멸자가 아닌 멤버 함수에 꼭 넣도록 해야 한다. 이것만은 잊지 말자! 1. 소멸자에서 예외가 빠져나가게 하지 말자. 2. 어떤 클래스의 연산이 진행되더가 던져진 예외에 대해서 사용자가 반응해야 할 필요가 있다면, 해당 연산을 제공하는 함수는 꼭 보통의 함수여야 한다. 관련링크 http://ikp..
댓글을 달아 주세요