오늘 읽은 범위
책에서 기억하고 싶은 내용
- 오류 코드보다 예외를 사용하라 (p 130)
- 오류가 발생하면 예외를 던지는 편이 낫다. 코드가 확실히 깨끗해진다. 코드 품질도 나아졌다.
- Try-Catch-Finally 문부터 작성하라 (p 132)
- 예외에서 프로그램 안에다 범위를 정의한다는 사실은 매우 흥미롭다.
- try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
- 먼저 가제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다.
- 미확인(unchecked) 예외를 사용하라
- 확인된 예외는 OCP를 위반한다. 메서드에서 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의 해야한다. 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.
- 예외에 의미를 제공하라 (p 135)
- 오류 메시지에 정보를 담아 예외와 함께 던진다. 실패한 연산 이름과 실패 유형도 언급한다. 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다.
- null을 반환하지 마라 (p 138)
- null을 전달하지 마라 (p 140)
- 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다.
- 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.
- 결론
- 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.
소감 및 생각
- 이번 장을 읽으면서 반성을 많이 하게 되었다. 나의 코드가 오류를 형편없이 분류한적이 많았다. 그게 잘못되었다고 생각한적이 없었는데 해결 방법을 보고 나의 방법이 잘못되었다는 것을 알게 되었다.
궁금한 내용 | 잘 이해되지 않는 내용