복구할 수 없는 오류의 전달
현실적으로 복구할 가능성이 없는 오류가 발생하면 신속하게 실패하고, 요란하게 실패하는 것이 최상의 방법이다.
- 비검사 예외를 발생
- 프로그램이 패닉이 되도록(패닉을 지원하는 언어를 사용하는 경우)
- 체크나 어서션 사용
암시적인 기술을 사용하면 오류 시나리오를 확인하거나 처리하기 위한 코드를 호출 체인의 상위에 있는 모든 호출자가 다 작성할 필요는 없다. 오류를 복구할 방법이 없을 때는 이것이 합리적이다. 왜냐면 이 경우 자신을 호출한 쪽에 오류를 전달하는 것 외에는 할 수 있는 방법이 없기 때문이다.
호출하는 쪽에서 복구하기를 원할 수도 있는 오류의 전달
비검사 예외와 명시적 오류 전달 기법중 어느 것을 사용하는지 정하기 전에 팀끼리 통일 시키는 것이 중요하다.
1. 비검사 예외를 사용해야 한다는 주장
비검사 예외를 발생시키면 코드 구조를 개선할 수 있다고 주징하는 개발자들이 있다. 오류가 높은 계층까지 거슬러 올라오면서 전달되고, 그사이에 있는 코드를 오류 처리를 할 필요가 없다.
중간에 있는 계층은 원한다면 예외 중 일부를 처리할 수 있지만, 그렇지 않으면 오류가 최상위 오류 처리 계층으로 전달된다. 사용자 응용 프로그램이라면 오류 처리 계층은 오류 메시지를 UI에 표시할 수 있다. 서버나 백엔드 프로세스라면 오류 메시지가 기록될 수 있다. 이 접근법을 핵심 장점은 오류를 처리하는 로직이 코드 전체에 퍼지지 않고 별도로 몇개의 계층에만 있다는 점이다.
2. 명시적 기법을 사용해야 한다는 주장
- 매끄러운 오류 처리
호출하는 쪽에 잠재적 오류를 강제적으로 인식하도록 하면 이러한 오류를 좀 더 매끄럽게 처리할 가능성이 커진다. - 실수로 오류를 무시할 수 없다.
명시적 오류전달 기법은 개발자의 위반 사항이 코드 변경 시에도 이와 비슷하게 분명하게 나타나도록 해준다.
이 책에서는 명시적 방식을 추천 하는것 같다 나도 역시 명시적 방식이 좀더 오류를 파악하기 수월하고 복구하기도 수월 할꺼라고 생각한다.
컴파일러 경고를 무시하지 말라
컴파일러 경고에 주의를 기울이면 코드베이스에 병합되기 훨씬 전에 코드로부터 프로그래밍 오류를 발견하고 제거할 수있다.
요약
- 오류에는 크게 두 가지 종류가 있다.
- 시스템이 복구할 수 있는 오류
- 시스템이 복구할 수 없는 오류
- 해당 코드에 의해 생성된 오류로부터 복구할 수 있는지 여부를 해당 코드를 호출하는 쪽에서만 알 수 있는 경우가 많다.
- 에러가 발생하면 신속하게 실패하는 것이 좋고, 에러를 복구할 수 없는 경우에는 요란하게 실패하는 것이 바람직하다.
- 오류를 숨기는 것은 바람직하지 않을 때가 많으며, 오류가 발생했다는 신호를 보내는 것이 바람직하다.
- 오류 전달 기법은 두 가지 범주로 나눌 수 있다.
- 명시적 방법: 코드 계약의 명확한 부분, 호출하는 쪽에서는 오류가 발생할 수 있음을 인지한다.
- 암시적 방법: 코드 계약의 세부 조항을 통해 오류에 대한 설명이 제공되거나 전혀 설명이 없을 수도 있다. 오류가 발생할 수 있다는 것을 호출하는 쪽에서 반드시 인지하는 것은 아니다.
- 복구할 수 없는 오류에 대해서는 암시적 오류 전달 기법을 사용해야 한다.
- 잠재적으로 복구할 수 있는 오류에 대해서는
- 명시적 혹은 암시적 기법 중 어느 것을 사용할지에 대해서는 개발자들 사이에서도 일치되는 의견이 없다.
- 필자의 의견으로는 명시적인 기법이 사용되어야 한다.
- 컴파일러 경고는 종종 코드에 문제가 있을 때 이에 대해 표시해준다. 이 경고에 주의를 기울이는 것이 바람직하다.
