프로그래밍에서의 오류 (명시적 vs 암시적 방법) #좋은코드나쁜코드 #4장 #Checked exception #Unchecked exception

* 본 아티클은, '좋은 코드 나쁜 코드' 4장을 기반으로 작성된 글입니다.

 

 

 

---

오류의 복구 가능성

• 복구 가능한 오류 → 시스템 전체에 영향을 주지 않도록 적절히 처리
  • ex: 네트워크 오류 (몇 초 기다리고 재시고) / 통계 기록 오류 (무시)
• 복구할 수 없는 오류 → 신속한 실패, 요란한 실패
• 호출하는 쪽에서만 오류 복구 가능 여부를 알 때 → 오류를 복구하기 원할 것이라고 판단 (대부분의 경우)
  • 호출하는 쪽에서 오류를 인지하도록 해야 한다.

견고성 vs 실패

오류가 있더라도 계속 진행하는 견고성, 오류를 처리하게 하거나 프로그램 작동을 멈추는 실패 사이의 트레이드 오프 → 대부분의 경우 실패가 적절

신속하게 실패해야 하고, 요란하게 실패해야 한다.

오류 전달 방법

• 명시적 방법 : 코드 계약 상 명확한 부분에 나타나 있어, 오류를 반드시 인지할 수 있음
  • ex : Checked exception, null 반환(null 안정성의 경우), Optional, Result, Outcome 반환(반환값 확인 필수인 경우)
• 암시적 방법 : 오류를 인지하지 못 할 수 있음
  • ex : Unchecked exception, 매직값, Promise(Future), Assertion, Check, Panic

Result형의 경우, 올바른 사용 방법을 팀 내에서 공유하고 있다고 가정해야, 명시적 방법이 된다.

자바의 @CheckReturnValue 애너테이션을 사용하면 결과값(Outcome) 확인을 반드시 해야해서, 명시적 방법이 된다.

복구할 수 없는 오류의 전달

Unchecked exception을 발생하거나, panic이 되도록 하거나, check 또는 assertion을 사용한다.

Unchecked exception을 사용하는 이유는, 어차피 복구가 불가능한 상황에서 호출하는 모든 계층에 extends를 다는 것이 번거롭기 때문이다.

그저 오류를 호출한 쪽에 전달하면 되고, 스택 트레이스를 통해 위치를 파악할 수 있다.

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

이 경우, Unchecked exception과 Checked exception(또는 명시적 기법) 사용을 두고 의견이 분분하다.

• Unchecked exception을 사용해야 한다는 주장
  • 코드의 구조가 개선된다 (일관된 계층에서 오류 처리)
  • 실용적임
• 명시적 기법을 사용해야 한다는 주장
  • 오류를 반드시 처리할 수 있고, 매끄럽게 처리할 수 있다.
    • 오류가 발생하는 지점에서 처리 or 던지기가 강제되므로, 발생 지점에서 오류를 인식하는 것만으로 매끄럽게 처리할 가능성이 높아진다.
  • 처리를 적절하게 하지 않아도, 코드 상에서 티가 잘 난다.
  • Unchecked exception이 적절하게 문서화되는 것은 어렵다.

필자는 명시적 방법을 추천한다.

하지만 많은 언어들이 Checked exception을 지원하지 않는 것에는, 실용적인 것을 포함하여 많은 이유가 있을 것이다.

아래 구절이 인상 깊다.

 

 

There is still one question left. What do water wings and checked exceptions have in common?

At the beginning you feel safer with them, but later they prevent you from swimming quickly.

Water wings가 안전하게 헤엄치는 것에 도움을 줄 수 있어도, 숙련되고 나면 빠르게 헤엄치는 것을 방해할 것이다.

컴파일러의 경고를 무시하지 마라

컴파일러의 경고를 잘 수정하는 것만으로도, 코드의 잠재적 문제를 해결할 수 있다.