Clean Code 제 6장. 오류 처리

오류와 예외에 대한 이야기.

0. 주관적인 결론.

• 오류 발생을 조건문으로 제어하기 보다는 예외를 던지는게 좋다.
• 예외에 의미있는 내용(실패한 연산이름, 유형, 해결법)을 넣자.
• null 생성보다 예외를 발생시키자.

1. 오류와 예외

오류보다 예외를 사용하자. 그러면 논리가 오류 처리 코드와 뒤섞이지 않으니까 호출자 코드가 더 깔끔해진다..

2. 오류를 아름답게 처리하는 법

A. 예외를 위한 테스트케이스를 먼저 작성하자.

먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통화하게 코드를 구현하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위내에서 트랜잭션 본질을 유지하기 쉬워진다.

B. 미확인 예외를 사용하라.

확인 예외 / 미확인 예외

확인 예외는 잘못된 코드보다 상황에서 발생하는 오류다. 예를 들어 파일을 Open하는 코드를 구현했지만, 정작 파일이 없어 발생하는 오류다. 그래서 예외처리를 구현하지 않으면 컴파일 시 오류가 발생한다.

미확인 예외는 런타임 시 잘못 구현된 코드로 발생하는 예외다. 컴파일 시 확인하지 않기 때문에 예외 처리가 없다면 프로그램을 종료된다. RuntimeException, NullPointException 등이 있다.

확인 예외 비용.

확인 예외는 OCP를 위반한다. 메서드에서 확인된 예외를 던졌는데 catch 블록이 3단계 위에 있다면, 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.

그리고 미확인 예외를 사용한다 해서 프로그램의 완성도가 떨어지는 경우는 많지 않다고 한다.

3. 클래스 감싸기 / 특수사례

오류는 발생위치도 중요하지만 해결법도 중요하다.

클래스 감싸기필요한 API를 외부로 한번 더 감싸 우리가 필요한 예외를 감싼 Class에서 추가 정의할 수 있다. (예외와 딱히 상관없지만…) 이 기법의 또 다른 장법은 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다. 프로그램이 사용하기 편리한 API를 정의하면 그만이다.

특수 사례 패턴은 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다. 그러면 클라이언트 코드는 예외적인 상황도 캡슐화 해서 처리하기 때문에 예외처리가 줄어든다.

4. Null

null 을 반환하지도 전달하지 말자. 위 클래스 감싸기나 특수 사례 패턴을 사용해서 최대한 만들지 말자.

5. 참조

• https://codevang.tistory.com/140