[클린 코드] 7장 오류처리

오류코드 보다 예외를 사용해라

오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 경우 

논리와 오류 처리 코드가 섞이기에 호출자 코드가 복잡해짐 + 호출 즉시 오류 확인해야 함

 

Try-Catch-Finally 문부터 작성하라

try 블록의 트랜잭션 범위부터 구현하게 되어 범위 내에서의 트랜잭션 본질을 유지하기 쉬워짐

 

미확인(unchecked) 예외를 사용하라

확인된 예외는 OCP(Open Closed Principle)를 위반

=> 하위의 메서드에서 확인된 예외를 던지면 상위의 선언부에 해당 예외를 정의해야 함

즉, 캡슐화가 깨진다. 이로 인해 발생하는 의존성이라는 비용은 이익보다 큰 경우가 대다수이다.

 

예외에 의미를 제공해라

예외를 던질 때는 전후 상황을 충분히 덧붙여 오류가 발생한 원인과 위치를 쉽게 파악할 수 있게 한다.

 

호출자를 고려해 예외 클래스를 정의하라

오류를 정의할 때 가장 중요한 요소는 오류를 잡아내는 방법이여야 한다.

Wrapper 클래스는 유용한데, 특히 외부 API를 사용할 때 유용하다.

Ex) 호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 return 해주는 Wrapper 클래스를 만든다.

=> 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어든다.

이는 추후의 라이브러리의 교체, 수정이 발생해도 비용이 적게 들어가고 Wrapper 클래스에 외부 API 대신 테스트 코드를 넣는 방식으로 테스트하기도 쉬워짐.

 

정상 흐름을 정의하라

클래스를 만들거나 객체를 조작하여 특수 사례를 처리하면, 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어짐

Ex) 유저 A의 결재 금액의 총합을 get하는 메소드를 호출하는데 결재 건 수 가 0인 상황일 때,

예외 클래스로 처리하기보다 결재 건 수가 0이라면 결과 객체의 결재 금액 총합을 0으로 만들어 return하게 만드는게 낫다.

 

null을 반환하지 마라

null 확인이 누락되도 문제, 너무 많이 확인해야해도 문제

=> 애초에 null을 반환하지 마라, 예외나 특수 객체를 반환하라

Ex) 직원들 객체를 가져오는 getEmployees()를 호출하는데 직원 수가 0인 경우

null을 반환하는 것이 아닌, 빈 리스트를 반환하는 것이다.

 

null을 전달하지 마라

인수로 null이 넘어오면 코드에 문제가 있단 소리

 

 

가독성과 안정성은 상충하는 목표가 아니다.
오류 처리와 비즈니스 로직을 분리하여 코드 유지 보수성을 높여보자.