[1부 코드와 마주보기] Chapter6 사람은 실수를 하기 마련

우리는 유일한 실수 예방 방법이 실수를 감지하는 것이고, 유일한 실수 감지 방법이 자유롭게 질문하는 것이라는 사실을 알고 있습니다. - J. 로버트 오펜하이머

 

코드 안에 있는 발생할 수 있는 모든 에러 상황을 반드시 처리해야만 한다.

 

어디에서 나왔나?

에러는 불완전한 프로그램에 포함되어 있는 버그와는 다르다.

사용자 에러

훌륭한 프로그램이라면 그럴 때 사용자의 잘못을 지적하고 교정하도록 도와줄 것이다.

프로그래머 에러

이것은 다른 곳에 있는 버그나 프로그래머의 실수로 인한 결과

예외상황

하드디스크 공간 없음, 네트워크 연결 실패

 

에러 리포트 메터니즘

리포트 안 하기

에러 상황을 무시하지 말자

리턴 값

간단한 에러 리포트 메커니즘은 함수가 성공/ 실패 값을 리턴 하도록 만드는 것

에러 상태 변수

함수의 리턴 값과 에러 상태 리포트간의 경쟁을 중재하려고 시도하는 방법

errno 변수를 사용하지 마라?

익셉션

종결 모델(termination model)

재개 모델(resumption model)

익셉션에 드는 비용은 에러 처리를 하지 않았을 때 치러야 하는 대가와 비교해 보면 정당한 것이다.

시그널

비교적 극단적인 에러 리포트 메커니즘

실행 환경이 작동 중인 프로그램에게 에러를 보낼 때 많이 사용

 

에러 감지하기

리턴 값

리턴 코드를 보고 함수의 실패 여부를 확인

에러 상태 변수

함수를 호출한 다음에 반드시 에러 상태 변수를 검사

익셉션

C++도 익셉션 규격을 지원한다. 익셉션 규격의 사용은 선택사항. 다른 것보다 성능상의 이유로 인해서 익셉션의 사용을 피하는 것이 관용적. JAVA에서와는 달리 익셉션 규격을 반드시 지키도록 만드는 일이 실행 시간에 발생

시그널

시그널 핸들러 설치

보고될 수 있는 에러는 하나라도 무시하지 마라

항상 에러 감지의 발판이 되는 코드를 작성해 두는 것이 좋은 습관이다.

익셉션의 동작을 문서화하는 것을 선호하자?

 

에러 처리하기

에러에 관한 몇 가지 중요한 정보

에러가 어디서 나왔는가?

당신은 무엇을 하려고 했었나

무엇이 에러를 불러일으켰습니까?

일이 왜 잘못 되었나

문제의 본질은 무엇입니까?

에러가 언제 일어났나

에러의 시간적인 지역성(locality)

에러의 심각성

에러를 고치는 방법

모든 에러 상황에 대해서 신중하게 생각하자

에러를 처리하는 시점

가능한 한 빨리

각각의 에러를 감지했을 때 처리

에러 코드를 리턴하는 함수에 대해서는 보통 이것이 최선책

가능한 한 늦게

익셉션이 이상적

에러를 처리하는 코드가 실제로 존재한다는 사실은 에러 처리를 언제 하느냐보다 훨씬 더 중요하다.

가장 적절한 콘텍스트 안에서 에러가 처리되도록 만들자. 에러 처리를 할 수 있을 정도로 에러에 대해서 알게 되는 즉시 그 에러를 처리하자

가능한 반응

로그기록, 보고, 복구, 무시, 전파

에러 메시지 다듬기

사용자는 프로그래머처럼 생각하지 않는다.

메시지를 지나치게 암호화하지 말자.

무의미한 에러 코드는 표시하지 말자

심각한 에러와 단순한 경고를 구별하자.

사용자 자신이 질문에 대한 응답의 결과를 충분히 알고 있다면 그냥 질문만 해라.

 

에러 일으키기

일반적인 에러 체크의 목록

함수의 모든 파라미터를 체크

관심 있는 실행 지점에서 불변 조건이 만족되는지 검사

외부에서 들어온 값은 사용하기 전에 모두 유효성 검사를 하자

모든 시스템 호출과 그 밖의 함수 호출의 리턴 상태를 체크하자

 

에러 관리하기

에러의 원인이 될 만한 일은 피하자

프로그램이나 루틴이 비정상적인 상황에서 어떤 동작을 할 것이 예상되는지 정하자

어느 컴포넌트가 어느 에러를 처리할 책임이 있는지 명확하게 정의하자

자신의 프로그래밍 습관을 체크하자

실패 가능성이 있는 코드를 작성할 때는 에러 감지 코드와 에러 처리 코드도 함께 작성하자. 나중으로 미루지 말자.