본문 바로가기

exception

예외를 전파하기 전에, 할당한 자원은 반드시 해당 개체에서 회수하라 에러에 대한 대책으로, 예외(exception)가 가지는 장점은 뚜렷하다. 기존의 함수 리턴값에 의존하는 구조로는 다루기 힘든 에러 처리도 예외를 사용하면 훨씬 구조적으로 처리할 수 있는 경우가 많다. 그러나, 제대로 된 예외 처리는 쉽지 않다. 예외에 신경쓰기 시작하면, 대체 어느 것이 예외에 안전한 코드인지, 그리고 예외를 처리하는 와중에도 발생 가능한 예외 때문에 상당히 골머리를 썩이게 된다. 기본 자료형 사이에서의 단순 연산은 예외를 일으키지 않지만, 문제는 사용자에 의해 생성된 자료형이다. 이들은 기본 자료형만으로 구성되어 있지 않기 때문에, 이런 자료형을 사용하는 도중 발생하는 예외는 프로그램 자료구조 일관성에 큰 영향을 미친다. 극단적으로 단순화해서 이야기한다면 힙에 관련된 연산은 언제나 예.. 더보기
예외 지정 기능은 신중히 사용하라 예외 지정(exception specification) 기능은 함수의 인터페이스에 발생 가능한 예외 종류를 명확하게 지정할 수 있다. 그러나, 기존 코드와의 호환성 때문에 이 기능은 신중하게 사용해야 한다. 즉, 다음과 같은 경우를 생각할 수 있다. void foo() throw(exception) { .... bar(); .... } bar() 함수가 foo() 함수 내부 정의에 사용되고 있는데, C++는 코드 호환성 때문에 bar()가 예외 지정 기능을 사용하지 않았더라도 이 코드는 컴파일이 가능하다. 만약 bar()가 exception 이외의 예외를 던진다면, 이 프로그램은 즉시 unexpected 함수를 호출하며, 대부분 abort()에 의해 프로그램이 종료된다. 즉, 예외 지정 선언은 주의 깊게.. 더보기
초기화 리스트를 사용한 생성자 호출 생성자가 참으로 말썽 많은 존재인 것은, 클래스가 명시적인 생성자를 가지고 있지 않을 경우, 컴파일러가 암묵적인 생성자로 클래스를 생성하기 때문이다. 만약 클래스가 반드시 명시적인 초기화가 필요한 데이터 멤버들을 가지고 있을 경우, 이런 방식으로 클래스 생성하는 것은 파국을 초래할 가능성이 높다. 또, 데이터 멤버들이 명시적인 초기화가 필요하지 않더라도, 이것은 역시 좋은 코드는 아니다. 기본 자료형이 아닌 사용자 정의 자료형일 경우 어떤 오버헤드가 있을지 알 수 없고, 템플릿 자료형이라면 그야말로 예측 불가이다. 만약, 이 데이터 멤버들이 예외를 던진다면 이 예외를 받아낼 방법이 전혀 없다. 즉, 여기서 할 이야기는, '디폴트 생성자를 제외한, 반드시 필요한 생성자를 제공해야 하며, 가급적 디폴트 생성.. 더보기