7. 오류 처리

• 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 불가능해진다.
• 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드가 아니다.

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

• 옛날에는 예외를 지원하지 않는 언어가 많아서 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법을 사용했다고 한다.
• 이제는 자바같은 경우 try, catch로 예외를 던진다. 코드블록을 통해 try, catch의 개념이 독립적으로 나타난다.

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

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

Unchecked Exception 활용 (미확인 예외)

• 확인 예외 : 컴파일 시점에서 발견되는 예외
• 미확인 예외 : 프로그램 로직의 오류로 인해 발생하는 예외. 런타임 시점에서 여부 확인.
• 막상 파이썬, 루비, C++ 등 은 확인된 예외를 지원하지 않지만 안정성있는 구현이 가능하다는 것을 증명했다.

예외에 의미를 제공하라

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

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

• 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
• 대다수의 상황에서 오류를 처리하는 방식
  1. 오류를 기록한다.
  2. 프로그램을 계속 수행해도 좋은지 확인한다.
• 위 경우는 예외 대응방식이 예외 유형과 무관하게 동일하다. 그래서 간결하게 코드를 고치기 쉽다. 호출하는 라이브러리 API를 감싸(wrapper)면서 예외 유형 하나만을 반환하면 된다.
• 특히 외부 API를 사용할 떄에는 감싸기 기법이 최선이다. 프로그램과 라이브러리의 의존성이 줄어들고, 나중에 다른 라이브러리로 갈아타도 비용이 적다.
• 감싸기 기법을 사용하면 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다.

정상 흐름을 정의하라

• 비즈니스 논리와 오류 처리가 잘 분리된 코드는 깨끗하고, 간결한 알고리즘으로 보인다. 그러다보면 오류 감지가 프로그램 언저리로 밀려난다.
• 외부 API를 감싸 독자적인 예외를 던지고, 코드 위에 처리기를 정의해 중단된 계산을 처리한다. 그렇지만 중단하지 않을 때가 적합한 경우는 있다. ex) 식비 청구 총계를 구하는 일에서 따로 청구하지 않은 날에는 중단이 아니라 기본 식비를 지급하는 방식으로 더 간결한 코드를 만들 수 있다. 이를 특수 사례 패턴(Special Case Pattern)이라 한다.

null을 반환하지 마라

• null을 반환하는 습관은 오류를 유발할 수 있다. null을 반환하는 코드를 사용한다면 호출자의 일거리가 늘어난다. null 확인을 못한 순간 애플리케이션은 통제 불능이 된다.
• 메서드에 null을 반환하고 싶은 유혹에서는 예외를 던지거나 특수 사례 객체를 반환하자.

null을 전달하지 마라

• 메서드에서 null을 반환하는 것도 나쁘지만 전달하는 방식은 더 나쁘다.
• 차라리 예외를 던지거나 assert 문을 사용하는 것도 방법이다.

결론

• 깨끗한 코드는 읽기도 좋지만 안정성도 높아야한다. 둘은 상충하는 목표가 아니다.오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.