복구 가능성에 따른 적절한 오류 전달 기법

 

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.108~119)를 읽고 정리한 글입니다.

복구할 수 없는 오류의 전달

현실적으로 복구할 가능성이 없는 오류가 발생하면 신속하게 실패하고, 요란하게 실패하는 것이 최상의 방법이다.

 

이를 달성하기 위한 방법으로

• 비검사 예외를 발생
• 패닉 (패닉을 지원하는 언어를 사용하는 경우)
• 체크나 어서션 사용

이 경우 프로그램이 종료되므로 개발자에게 강력하게 경고하고, 스택 트레이스와 줄 번호를 제공하여 오류 발생 위치를 명확하게 알린다. 또한, 복구할 수 없는 오류일 경우 호출한 측에서 오류를 단순히 전달하기 때문에, 암시적 전달 방식으로 별도의 처리 코드 작성이 필요 없도록 하는 게 효율적이다.

호출하는 쪽에서 복구하기를 원할 수도 있는 오류의 전달

개발자들 사이에서 호출하는 쪽에서 복구하기를 원할 수도 있는 오류를 전달하고자 할 때 그 방법에 대해 의견이 엇갈린다.

비검사 예외를 사용해야 한다는 주장

1. 코드 구조 개선
   • 암시적 방법을 사용하면 대부분의 오류 처리가 몇 개의 계층에서만 이루어지며, 오류 처리 로직이 코드 전체에 퍼지지 않고 특정 계층에 집중되므로 코드 구조가 개선된다.
2. 개발자들이 무엇을 할 것인지에 대해서 실용적이어야 함 (개발 효율성)
   • 명시적 오류 전달이 과도하면 잘못된 처리가 발생할 가능성이 높다.
   • 특히, 함수를 수정하여 명시적으로 오류를 전달할 경우(예: Checked Exception 발생 시 함수 시그니처에 추가), 해당 함수를 호출하는 모든 코드뿐만 아니라 상위 계층의 코드까지 수정해야 할 수도 있다.
   • 이로 인해 작업량이 증가하여, 오류를 숨기고 함수 내에서 처리하려는 경향이 생길 수 있다.

명시적 기법을 사용해야 한다는 주장

1. 매끄러운 오류 처리
   • 비검사 예외를 사용하게 되면 모든 오류를 매끄럽게 처리할 수 있는 단일 계층을 갖기 어렵다
   • 호출하는 쪽에서 잠재적인 오류를 강제적으로 인식하도록 하면 오류를 매끄럽게 처리할 수 있다.
2. 실수로 오류를 무시할 수 없다.
   • 비검사 예외를 사용하게 되면 적극적인 의사결정이 들어갈 여지가 줄어들고 오류를 처리하지 않는 일이 일어나기 쉽다.
   • 검사 예외를 사용하게 되면 코드 검수시 명확하게 드러나게 되고 이런 잘못된 코드를 차단할 가능성이 커진다.
3. 개발자들이 무엇을 할 것인지에 대해서 실용적이어야 함 (개발 효율성)
   • 비검사 예외들이 코드베이스 전반에 걸쳐 문서화된다는 보장이 없다. 따라서 어떤 코드가 어떤 예외를 발생시키는지 확실히 알지 못하게 되고, 예외를 처리하는 것이 어려워지고 리소스가 많이 들게 된다.
   • 이를 해결하기 위해 모든 예외를 다 아우리는 예외를 처리하는 것은 바람직하지 않다.

 

책의 필자는 각 방식에 장단점이 있지만, 경험상 오류에 비검사 예외를 사용하면 오히려 더 심각한 문제가 발생할 수 있다고 판단하여 명시적 방법을 권장한다.