예외 안전성이란 무슨 말인가?
"예외적 상황에 대해서 안전한가?"에 대한 말이다.
왜 확보해야 하는가?
.. 코딩중에 컴파일타임에 에러를 다 찾아내면 좋겠지만, 컴파일 타임에 찾지 못하는 에러들은 정말 찾기가 힘들어진다. 그렇기 때문에, 예외적 상황에 대해서 대처를 해야지만 디버깅이 용이해지고, 프로그램 자체도 더 견고해지기 때문에 확보해야 한다.
함수들의 예외 안전성은 어떻게 동작해야 하는가?
1. 자원이 절대 새도록 만들지 않는다.
2. 자료구조가 더렵혀지는 것을 허용하지 않는다.(.. 이 말은 자료가 자료가 아닌게 되는 상황을 말한다.)
그렇다면, 예외 안전성을 갖춘 표준 보장은 무엇인가?
1. 기본적인 보장(basic guarantee) : 예외 발생에 있어, 자원 누수를 시키지 않겠다는 보장
2. 강력한 보장(strong guarantee) : 성공 아니면 본래의 상태로 되돌리겠다는 보장
3. 예외불가 보장(nothrow guarantee) : 예외를 절대로 던지지 않겠다는 보장
이렇게 3가지가 있다.
보통 1,2로 선택을 한다.
2번째인 강력한 보장을 어떻게 설계 하는가?
많은 설계 방법이 있지만, 그중 하나가 바로 복사-후-맞바꾸기(copy-and-swap)이다. 이 설계 방법은, 사본을 만들고 수정한 후 원본과 맞 바꾸어 버리는 것이다. swap의 으로 어떻게 하는게 효율적인지는 전장에서 했으니 넘기고.. 사본을 수정한것이기 때문에, 예외가 발생된다해도 원본을 건들지 않으니, 2번을 충족하는 상태이다.
하지만, 이 2번을 충족하기 위해선 모든 함수들이 이 2번을 충족해야 되므로..(여차저차 이야기가 있지만 생략하고) 보통은 "기본적인 보장(basic guarantee)"을 하려 한다.(사실 강력한 보장은 강력하기 때문에, 컴퓨터도 힘들고 사람도 힘들다..)
.. 부수적 이야기
40년 전에는 코드에 goto문을 도배하는것이 좋은 프로그래밍이라 했다.
20년 전에는 전역적으로 접근할 수 있는 데이터를 두는것이 좋은 프로그래밍이라 했다.
10년 전에는 예외 영향을 생각하지 말고 함수를 만드는것이 좋은 프로그래밍이라 했다.
지금은 예외 안전성을 위해서 힘차게 싸우자는 이야기이다!
이것만은 잊지 말자!
1. 예외 안전성 보장은 메모리 누수와 자료구조를 더럽히지 않는것이다.
2. 강력한 예외안전성 보장은 복사 후 맞바꾸기이다.
3. 어떤 함수의 예외 안전성 보장 강도는 그 함수 내부 호출되는 함수들의 가장 낮은 예외 보장을 넘지 말아야 한다.
개인적인 생각
몇일전 서버프로그래밍을 하면서 느낀것은... 성능도 좋지만, 디버깅도 좋아야 한다는 것이다. 디버깅을 줄기자게 해서 서버가 뻑은 안났으니, 뭐 반은 된건가?
관련링크
http://beforu.egloos.com/1224946
"예외적 상황에 대해서 안전한가?"에 대한 말이다.
왜 확보해야 하는가?
.. 코딩중에 컴파일타임에 에러를 다 찾아내면 좋겠지만, 컴파일 타임에 찾지 못하는 에러들은 정말 찾기가 힘들어진다. 그렇기 때문에, 예외적 상황에 대해서 대처를 해야지만 디버깅이 용이해지고, 프로그램 자체도 더 견고해지기 때문에 확보해야 한다.
함수들의 예외 안전성은 어떻게 동작해야 하는가?
1. 자원이 절대 새도록 만들지 않는다.
2. 자료구조가 더렵혀지는 것을 허용하지 않는다.(.. 이 말은 자료가 자료가 아닌게 되는 상황을 말한다.)
그렇다면, 예외 안전성을 갖춘 표준 보장은 무엇인가?
1. 기본적인 보장(basic guarantee) : 예외 발생에 있어, 자원 누수를 시키지 않겠다는 보장
2. 강력한 보장(strong guarantee) : 성공 아니면 본래의 상태로 되돌리겠다는 보장
3. 예외불가 보장(nothrow guarantee) : 예외를 절대로 던지지 않겠다는 보장
이렇게 3가지가 있다.
보통 1,2로 선택을 한다.
2번째인 강력한 보장을 어떻게 설계 하는가?
많은 설계 방법이 있지만, 그중 하나가 바로 복사-후-맞바꾸기(copy-and-swap)이다. 이 설계 방법은, 사본을 만들고 수정한 후 원본과 맞 바꾸어 버리는 것이다. swap의 으로 어떻게 하는게 효율적인지는 전장에서 했으니 넘기고.. 사본을 수정한것이기 때문에, 예외가 발생된다해도 원본을 건들지 않으니, 2번을 충족하는 상태이다.
하지만, 이 2번을 충족하기 위해선 모든 함수들이 이 2번을 충족해야 되므로..(여차저차 이야기가 있지만 생략하고) 보통은 "기본적인 보장(basic guarantee)"을 하려 한다.(사실 강력한 보장은 강력하기 때문에, 컴퓨터도 힘들고 사람도 힘들다..)
.. 부수적 이야기
40년 전에는 코드에 goto문을 도배하는것이 좋은 프로그래밍이라 했다.
20년 전에는 전역적으로 접근할 수 있는 데이터를 두는것이 좋은 프로그래밍이라 했다.
10년 전에는 예외 영향을 생각하지 말고 함수를 만드는것이 좋은 프로그래밍이라 했다.
지금은 예외 안전성을 위해서 힘차게 싸우자는 이야기이다!
이것만은 잊지 말자!
1. 예외 안전성 보장은 메모리 누수와 자료구조를 더럽히지 않는것이다.
2. 강력한 예외안전성 보장은 복사 후 맞바꾸기이다.
3. 어떤 함수의 예외 안전성 보장 강도는 그 함수 내부 호출되는 함수들의 가장 낮은 예외 보장을 넘지 말아야 한다.
개인적인 생각
몇일전 서버프로그래밍을 하면서 느낀것은... 성능도 좋지만, 디버깅도 좋아야 한다는 것이다. 디버깅을 줄기자게 해서 서버가 뻑은 안났으니, 뭐 반은 된건가?
관련링크
http://beforu.egloos.com/1224946
'책 정리 > Effective C++ 3판' 카테고리의 다른 글
항목 34: 인터페이스 상속과 구현 상속의 차이를 제대로 파악하고 구별하자. (0) | 2008.07.09 |
---|---|
항목 33: 상속된 이름을 숨기는 일은 피하자 (4) | 2008.07.02 |
항목 32: public 상속 모형은 반드시 "is-a(...는 ...의 일종이다)"를 따르도록 만들자. (0) | 2008.07.02 |
항목 31: 파일 사이의 컴파일 의존성을 최대로 줄이자 (0) | 2008.07.02 |
항목 30: 인라인 함수는 미주알고주알 따져서 이해해 두자 (0) | 2008.07.01 |
항목 28: 내부에서 사용하는 객체에 대한 '핸들'을 반환하는 코드는 되도록 피하자. (0) | 2008.06.28 |
항목 27: 캐스팅은 절약, 또 절약! 잊지 말자. (0) | 2008.06.26 |
항목 26: 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자. (0) | 2008.06.25 |
항목 25: 예외를 던지지 않는 swap에 대한 지원도 생각해 보자 (0) | 2008.06.24 |
항목 24: 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멘버 함수를 선언하자 (0) | 2008.06.15 |
최근댓글