반응형
TIL (Today I LeTIL (Today I Learned)
2022.03.03
오늘 읽은 범위
7장. 오류처리
책에서 기억하고 싶은 내용을 써보세요.
- try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. (p.132)
- 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. (p.133)
- 오류 메시지에 정보를 담아 예외와 함께 던진다. (p.135)
- 오류는 많고 분류하는 방법도 다양하다. 그러나 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이다. (p.135)
- 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. (p.137)
- 메서드에서 null을 반환하는 방식도 나쁘지만, 메서드로 null을 전달하는 방식은 더 나쁘다. (p.140)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 오류 코드로 오류를 잡아내기보다는 예외를 사용해서 코드를 더 깔끔하고 직관적이게 작성해야겠다.
- 미확인 예외를 사용하라고 한다. 흔히 알려진 Unchecked Exception이다. RunTimeException의 하위 예외들이 미확인 예외에 포함된다. 왜 확인된 비용을 사용하지 마라고 하는 걸까? 바로 OCP를 위반하기 때문이다. OCP는 확장에는 열려있고, 수정에는 닫혀있어야 한다는 원칙이다. 예시로 메서드에서 확인된 예외를 던졌는데, catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 고치므로 OCP를 위반하는 것이다. 또 최하위에서 trhow 절을 추가하면 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다. 이런 이유로 인해 Checked Exception 말고 Unchecked Exception을 사용하라는 것 같다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 특수 사례 패턴이란?
반응형
댓글