토비의 스프링 '4장 예외'를 읽기모임 중에 기억에 남는 말들, 생각거리, 추천 링크들을 정리합니다.

1. 생각거리

우리의 예외 처리 전략은 뭐지?

잠시 생각해 본다. Netty 채널 파이프라인 내에서 발생한 시스템 예외는 파이프라인 끝 단에 위치한 예외처리 핸들러로 전달되어 로깅 시스템으로 전달된다. 애플리케이션 로직 상에 발생할 수 있는 예외는 예외 상황을 미리 체크해서 별도의 사용자 이벤트 핸들러로 던지는 전략을 사용하고 있다. 즉 시스템 예외가 던져지기 전에 상황을 인지해서 사용자가 이해할 수 있는 메시지를 로깅하려 노력한다. 예를 들면 수신한 메시지 ID가 정의되어 있지 않으면 메시지 디코딩 로직에서 디코딩 Function이 null 값을 가지게 되는데 null 함수로 apply() 메서드를 호출하기 전에 체크해서 사용자 이벤트 핸드러로 “정의되지 않은 메시지가 수신되었다”는 상황을 알리고 실행을 중단한다.

복구할 수 있는 예외가 있나?

현재 수행 중인 프로젝트에 예외를 받아서 예외 상황을 복구하는 케이스가 있는지 한 번 살펴보자. 간단히 살펴보니 예외를 복구 할 수 있는 동작은 외부 시스템 IP, Port를 잘못 입력하여 연결이 실패한 경우, 설정 값을 잘못 입력한 경우 정도인데 애플리케이션이 자동으로 복구할 수 있는 경우는 없다. 사용자에게 구체적으로 무엇이 잘못 입력되었으니 다시 입력해 보라고 알리는 정도의 복구 전략만 존재한다.

2. 모임중 기억에 남는 말말말

• 사용자가 예외를 복구할 수 있는 방법이 없는 경우 Unchecked/Runtime 예외로 던져서 빠르게 실패하도록 하는 전략인 것 같았다.
• 예외를 개별적인 커스텀 클래스로 정의하는 것과, 하나를 두고 내부 코드만 바꾸는 것 어떤게 나을까?
• try-catch 비용 처리는 감당할만한가? 성능상에서 큰 이슈는 되지 않는다.
• Optional을 반환값으로 적극적으로 쓰는 것은 좋습니다.
• 커스텀 예외를 정의해서 뭔가 캐치해서 할 일이 있는지, 의미가 있는지 고민해 볼 필요가 있다.
• 스프링 JdbcTemplate이 단지 사용자의 편의를 위해(예외를 체크하지 않아도 되도록) SQLException(Check Exception)을 DataAccessException(Unchecked/Runtime Exception)으로 래핑한 것이 아니라 데이터 접근 기술에 독립적으로 만들기 위해 이런 설계가 만들어 졌다고 생각하니까 되게 새로웠다.
• 프로그램이 잘못 작성되었음을 의미하는 예외가 있고(Assertion으로 체크) 진짜 외부의 예외적인 상황 때문에 발생하는 예외 둘을 잘 구분하는 것이 중요하다고 생각한다.
• 예외 커스텀 파일이 너무 많아지는 것 같으면 구조적으로 중첩 클래스를 사용하기도 합니다.
• 최소한 ERROR 레벨에 Stack Trace를 남기는 것이 좋습니다.
• 실제 사용자 입출력에 의한 예외는 추적할 수 있어야 서비스가 운영 가능하지 않을까요?

3. 추천 링크

• Improved Java Logging with Mapped Diagnostic Context (MDC)