토비의 스프링 ‘4장 예외’ 장을 읽고 배우고 느낀점을 정리합니다.

스프링의 예외 전환

스프링 JdbcTemplate이 사용자의 체크를 필수적으로 요구하는 Checked Exception을 Unchecked Exception으로 전환해서 던진다는 것(복구 가능성이 거의 없는 예외를 위해 애플리케이션에서 불필요한 catch, throws 코드를 반복하지 않아도 되도록)과 다양한 DB 및 DB 접근 기술에서 발생하는 예외를 일관성있게 그리고 사용자 관점으로 추상화해서 던져주려 노력한다는 걸 이해하게 되었습니다. 그래서 나도 이런 예외 처리 전략을 따라 애플리케이션을 확장해 나가면 좋겠다는 생각을 하게 됩니다. 책 초반에 스프링을 학습할 때 먼저 스프링이 지향하는 것을 이해하고 그리고 그것을 확장해 나가는 것이 중요하다고 하셨는데 아 이런 부분을 말씀하시는 거구나 느끼게 됩니다.

예외에도 역할과 책임

예외처리를 고민할 때 역시 역할과 책임을 잘 나누어서 누가 예외를 처리할지(나, 나를 호출한 쪽, 별도의 예외처리 시스템) 의도를 가지고 설계 하는것이 중요하고, 또한 서로 다른 역할을 가진 모듈에 예외를 던질 때에는 나의 관점(로우레벨, 기술적)의 예외 메시지를 사용자 관점의 추상화된 예외 메시지로 전환해 주는 개념을 학습하게 되어 좋았습니다.

서로 다른 하드웨어를 제어하는 설계 모델

JDBC가 여러 벤더에서 구현한 데이터베이스를 일관된 방법으로 접근할 수 있는 인터페이스를 제공한다는 것과 스프링 JdbcTemplate이 여러 데이터베이스의 예외를 일관성있게 추상화하는 방법이 인상적이었습니다. 제가 개발하는 분야에서는 다른 벤더의 하드웨어를 일관되게 처리하는 방법을 많이 고민하는데 좋은 설계 모델을 만난 것 같습니다. 하드웨어 제어 모듈 설계 시 JDBC 처럼 제어 인터페이스를 맞추어 주는건 그리 어렵지 않았는데, (예외메시지 처럼)하드웨어의 상태를 처리하는 일은 워낙 다른 부분이 많아서 추상화가 어려웠습니다. 지금은 그냥 벤더 별로 각각 WEB까지 처리하고 있는데 시간이 되면 전체를 추상화한 테이블을 만들고 벤더별 실제 상태를 매치시키는 것도 하나의 방법이겠구나 생각했습니다.

별도의 예외처리 시스템

애플리케이션이 처리하지 않은 예외를 처리해주는 별도의 시스템이 있음을 새삼 깨닫게 되었습니다. 따라서 애플리케이션 내에서 복구할 수 없는 예외는 catch, throws 문을 주렁주렁 달리지 않고 빨리 예외 처리 시스템으로 던져지는 것이 나음을 분명하게 이해하게 된 것 같습니다. 또한 쓰레드 내에서 처리되지 않는 예외가 발생하면 해당 쓰레드만 종료된다는 개념도 분명하게 이해하게 된 시간이었습니다.

습관

책에서 자주 강조하시는 것 같습니다. 예외를 잡아서 처리하지 않는 난감한 코드를 향해 “코딩 연습이나 예제를 잠깐 만드는 경우라도 그래선 안된다.”라고 말씀해 주시는데 늘 조금의 귀찮음을 뚫고 좋은 습관을 형성해야 겠다고 생각했습니다.