TIL (Today I Learned)
2022.05.09

오늘 읽은 범위
7장. 오류 처리

---

책에서 기억하고 싶은 내용을 써보세요.

• 오류 코드보다 예외를 사용하라 (p.130)

• Try-Catch-Finally 문부터 작성하라. (p.132)
  • try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.

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

• 미확인 예외를 사용하라. (p.133)
  • 확인된 예외 (..) 메서드 모두가 선언부에 해당 예외를 정의해야 한다. (..) 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다. (..) ! throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.

• null을 반환하지 마라 (p.139)
  • 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다.

• null을 전달하지 마라. (p.140-141)
  • 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는
    방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적
    이다. 즉, 인수로 null이 넘어오면 코드에 문제가 있다는 말이다.

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

😏 확인된 예외, 구체적인 오류처리를 하면 장점만 있다고 생각했다.

오류 case를 잡아내는 것에만 중점을 둬서, 자세하고 확실한 경우를 잡아내는 것이 우선이라고만 생각했다. 기존 코드를 수정하는 것도 비용에 포함된다고는 생각을 못했었다. 기회비용을 잘 따져 선택하는 것이 중요하다 생각이 되었다.
책을 읽을수록 당연하다고 생각하고 신경쓰지 않았던 것들을 의식하게 되어서 너무 좋다.

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• asset
  : Assert는 개발/테스트 단계에서 파라미터가 제대로 넘어왔는지 계산이 제대로 됬는지 혹은 특정 메소드가 작동하는 한계상황(Null이 들어오면 작동안함)을 정하는 용도로 사용한다.

  참고 블로그 | Java에서 assert 제대로 쓰기