이 글에서 분류한 기준은 책의 내용을 바탕으로 주관적인 견해로 재정리해본 것입니다.

클린 코드와 오류 처리의 연관성

• 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다.
  • 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기 힘들다.
• 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면, 깨끗한 코드라 부르기 어렵다.
• 깨끗한 코드는 읽기도 좋아야 하지만 안전성도 높아야 한다.

오류 처리

오류 코드 vs 예외

• 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법은 함수를 호출한 즉시 오류를 확인해야 하기 때문에 호출자 코드가 복잡해진다.
• 따라서 오류가 발생하면 예외를 던지는 편이 낫다.
  • 호출자 코드가 더 깔끔해진다.
  • 논리가 오류 처리 코드와 뒤섞이지 않는다.

try-catch-finally문

• try 블록은 트랜잭션과 비슷하다.
  • try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
• 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다.
  • try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.

Unchecked 예외

Checked vs Unchecked

• checked 예외는 OCP(Open Closed Principle)을 위반한다.
  • 메서드에서 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면, 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다.
  • 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.
  • throws 경로에 위치하는 모든 함수가 최하위 하수에서 더지는 예외를 알아야 하므로 캡슐화가 깨진다.
• 따라서, Unchecked 예외를 사용하라.

예외에 의미를 제공하라

• 예외를 던질 때는 전후 상황을 충분히 덧붙이면 오류가 발생한 원인과 위치를 찾기 쉬워진다.
• 오류 메시지에 정보를 담아 예외와 함께 던진다.
  • 실패한 연산 이름과 실패 유형도 언급한다.
  • 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 전달한다.

호출자를 고려한 예외 클래스 정의

• 오류를 분류하는 방법은 많다.
  • 오류가 발생한 위치로 분류
  • 오류가 발생한 컴포넌트로 분류
  • 오류 유형으로 분류
• 애플리케이션에서 오류를 정의할 때 프로그래머에서 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
• 외부 API를 사용할 때는 감싸기 기법을 사용한다.
  • 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
  • 다른 라이브러리로 갈아탈 때 비용이 적다.
  • 프로그램을 테스트하기 쉬워진다.
  • 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다.

정상 흐름을 정의

• 앞 절에서 충고한 지침을 따른다면 비즈니스 논리와 오류 처리가 잘 분리된 코드가 나온다.

특수 사례 패턴 (Special Case Pattern)

• 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다.
• 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하므로, 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
  • ex. DAO에서 오류가 아닌 항상 객체를 반환하도록 한다.

Null 반환 금지

• null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다.
• null을 반환하는 대신 예외를 던지거나 특수 사례 객체를 반환한다.
• 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다.
  • 많은 경우, 특수 사례 객체가 손쉬운 해결책이다.

Reference

참고 서적

📔 Clean Code