범위

• 7장. 오류처리

깨끗한 코드와 오류 처리의 연관성

여기저기 흩어진 오류 처리 코드가 실제 코드가 하는 일을 파악하기 어렵게 만든다.

1. 오류보다 예외를 사용하라!

   
   💡 예외를 사용했다가 팀장님한테 혼났다. 예외 때문에 컨텍스트를 인터셉트하는 비용이 발생한다고…. 알쏭달쏭….

   Performance Effects of Exceptions in Java | Baeldung

2. try-catch-finally 문부터 작성하라!

3. 미확인 예외를 사용하라!

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

   • 하위레벨의 코드를 변경하면 상위레벨의 메서드 선언부를 전부 고쳐야 하기 때문에

4. 예외에 의미를 제공하라!

   • 오류 메세지에 정보를 포함 (ex. 실패한 연산 이름, 실패 유형 등)

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

   1. 오류 정의 시 가장 중요한 관심사는 “오류를 잡아내는 방법”

   2. 외부 API를 사용할 때는 감싸기 기법이 최선

      1. 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어듦

      2. 테스트 용이

      3. 특정 업체가 API를 설계한 방식에 종속되지 않음

   💡 “감싸기 기법”이라고 명명한 방법이 정말 공감이 간다. 특히 spring과 연관이 없는 외부 라이브러리를 통해 repository를 작성할 때, 커넥션이 불안정한 경우가 많아 repo 내에서 try catch 를 작성하고 catch에 걸리면 빈 리스트나 맵을 반환하도록 만들었는데 정답이라고 말해준 것 같아 기분 좋음. 저자도 말했지만 try catch가 그닥 예쁘진 않다. 앞으로 service 단에서는 try catch 작성을 지양하고 모두 하위레벨 메소드로 빼버려야겠다. 그리고 service 에서는 빈 값만 던지도록 해야지.

6. null을 반환도 전달도 하지마라!

   • 예외 던지기, 특수 사례 객체 반환, 감싸기 기법으로 대체

   💡 아마 그렇게 탄생한 것이 코틀린 아닌가 싶다. 자바로 개발하다가 처음 코틀린을 접했을 때는 뭐가 다른가 싶었다. 그러나 적어도 내가 정의한 자료 구조에 대해서는 null 을 다루기가 무지막지하게 간단해졌다. (물론 뒷받침하는 IDE도 매우 쩔었다.) 잠시 경험했던 타입스크립트에서도 null 처리에 특화되어 있었다. 지난 세월동안 개발자들이 null에 정말 된통 당했나보다.