Spring MVC 에서 Exception 처리 설계 - 1부

사실 Spring 을 사용하기 전까지 Exception 은 별로 고민거리가 아니었다. 발생한 Exception 을 처리하는 건 고민거리 이지만 Exception 자체는 그냥 로그찍고 던지면 끝.....

각각의 Exception 은 공통에서 정해진 Message 가 있다면 그거 찍고 없다면...."문제가 발생했습니다. 관리자에게 문의하세요"... 끝 , 이런식 이었다...

Spring 에서 Exception 처리해주는 이것 저것들을 보면서 뭔가 정리된게 필요하다고 느꼈다. 실제 System 에서 적용하려니 뭔가 정해진 Rule 도 없고 그냥 이런게 있고 저런게 있고 필요하면 쓰고 아님 말고...뭐 이런식....ㅡㅡ;

그래서 나름 정리해 보기로 했다.

1. Exception 은 뭔가?

정리를 하기 위해서는 정의가 필요하다. 일단 Exception 은 무엇인지 고민해 보기로 했다. 

내가 내린 정의는 시스템이 "내가 원하는데로 작동하지 않는 상황" 이다. 

2. Exception 분류는?

JAVA 언어적인 분류는 모르겠고 알아도 별로 소용도 없으니 내가 내린 분류는 딱 두가지 이다. "내가 예상했던것과 내가 예상하지 못한것 " 여기서 내가 예상하지 못한건 어쩔 수 없으니 일단 그렇게 넘어가고 내가 예상했던것은 시스템 사용자 입장에서는 다시 두가지로 나눤다. 

첫째, 내가 예상했지만 사용자에게 알려주면 처리가 가능한것, 둘째, 내가 예상했지만 사용자에게 알려줘도 해결이 불가능 한것. 그래서 크게 보면 세가지 Exception 이 존재한다.

3. Exception 분류에 대한 처리방법

   3-1 내가 예상하지 못한것 - SystemException 이라고 하자

내가 예상하지 못했으니 뭐 어떻게 할 수 없다....그냥 로그찍고 사용자에게 Notice 하는 방법밖에.....이 자료를 수집해서 이 Exception 들을 가능한 내가 예상한것들의 범위에 포함시키는 행위를 지속적으로 해야 한다는건 일단 나중문제다. 현재는 난 어쩔 수 없다는 것

일반적으로 JDK에서 발생하는 Runtime Exception 들이 여기 해당 되는 것 같다.

    3-2. 내가 예상했지만 사용자가 어찌 할 수 없는것 - ApplicationException 이라고 하자

난 예상은 했지만 나도 어쩔 수 없고 사용자도 어쩔 수 없는 것들.....예를 들어 IOException 같은 것들이다. 연결이 끊어 졌는데 ..... 뭐 어쩌라구..... 이런식이지... 역시 할 수 있는게 별루 없다....

    3-3. 내가 예상했고 사용자가 처리해 주면 처리 가능한 것 - ValidException 이라고하자

보통 이런 것을을 Validation 이라고 한다....화면에서 하던지 서버에서 하던지 뭔가 interactive 하게 작동해야 하는 것들....예를 들어 PK 중복 같은 것들이다....사용자가 PK를 입력한다면 사전에 SELECT 를 해서 중복을 알려주던지 아님 DB Exception 을 잡아서 처리하던지....참고로 난 후자를 선호한다....SELECT를 해서 체크하더라고 실제 데이터가 들어오는 시점에서 다시 데이터의 변경이 발생할 수 있기 때문에 그냥 DB Exception 을 받아서 처리하는게 깔끔하다...

4. Exception Architecture 가이드

일단 CommonException interface를 만든다...모든 Exception 에서 implements 하기 때문에 가능한 가볍게 가져간다.toString(), getErrorCode(), setErrorCode(), getErrorMessage(), setErrorMessage() 정도? ....해당 시스템의 정책에 따라서 천차 만별이다..

내가 어쩔 수 없는 에러는 SystemException (implements CommonException) 이라고 정의한다....역시 별루 할 수 있는게 없다....로그 남기고 나중에 분석 가능하게 하는 정도?

내가 예상했지만 어쩔수 없는 에러는 ApplicationException 이라고 정의한다....역시 별루 할 수 있는게 없다.....하지만 사용자와 잘 협의하면 사전에 방지 가능한 것들로 변환 가능하다.

내가 예상했고 사용자가 처리 할 수 있는 것들을 ValidException 이라고 정의한다. abstract 로 하고 개발자들이 필요시 각각의 Exception 들을 상속받아서 구현하라고 한다. 화면에서 처리하더라도 서버에서 다시 체크하는게 좋다. 입력값에 대한 길이,한영,숫자,메일포맷정상 여부 등등.....

중요한 것은 내가 예상했고 사용자가 기다리면 처리가능한 것들도 있다. 

이런 것들도 사용자와 interaction 할 수 있으므로 ValidException 으로 처리한다. 

예를 들어 시스템에 NAS 가 달려있는데 이게 가끔 죽거나 Network Traffic 에 문제가 있다면 사용자에게 "현재 시스템 저장공간에 부하가 많아서 좀 기다렸다가 한가할때 써봐라.." 하는 메시지를 보여줄 수 있다는 거다...(친절하게....)

5. 적용은?

사실 이러한 Exception 처리기준은 반드시 Spring 을 써야만 적용가능한 것은 아닐것이다. 대부분의 시스템에서 이런 기준을 적용한다면 Exception 이 진짜 Exception 으로 되는 것을 어느정도 통제가능할 것으로 생각된다.

실제 몇몇 프로젝트에서 시도해 본 결과 개발초기에는 거의 SystemException 들이다.......QA를 거치고 나면 AppliationException 들이 들어난다. 그리고 사용자 테스트와 시연등을 진행하면 ValidException 들이 늘어나기 시작한다.....문제는 시스템 종료일자가 다가올 수록 일이 늘어난다......(T,.T;) 

초기에 프로젝트 계획시 이러한 것을 스케줄에 반영하지 않았다면 헬 을 맛볼수도 있다.....