스터디로 File 업로드, 다운로드 로직을 작성하던 도중, 특정 부분에 빨간줄이 등장했다. 자연스럽게 마우스 가져가보니 Exception!. 별생각 없이 add thrwos declaration 클릭. 상황종료.
이처럼 예외 처리에 큰 의미나 생각을 부여하지 않았다.
두둥등장한 에러.
그러던 어느날, 고객사측에서 에러 문의가 들어와 로그를 확인해보니 딱 봐도 DB 예외로 보이는 ERDBException이 발생하고 있었다.(커스텀 익셉션인 것!) 그래서 DB 예외라는 필터를 머릿속에 장착한 뒤 로직을 확인해보니... 이게웬걸.. 모든 예외에 대한 처리를 ERDBException으로 던지고있었다.
그리고 깨달았다. 예외처리를 제대로 하지 않으면 유지보수 시 혼란을 초래할 수 있다는 것을...
2. 예외? 에러?
예외에 대한 기본 개념을 정립하기 위해 구글링을 하니 "예외와 에러의 차이" 가 눈에 들어왔다. 사실 이 두 개념은 비슷하다고 생각했으나, 막상 확인해보니 예외 공부에 아주 중요한 키포인트가 됐던 내용이었다.
정리하면 에러는 시스템 레벨에서 발생하는 아주 심각한 수준의 문제이다. 예를들면 서버의 과부하가 걸려 발생하는 OutOfMemory 같은 것이다. 이러한 에러는 프로그래머가 미리 예측하지 못하며 로직으로 처리할 수 없다.
이에반해 예외는 프로그래머가 작성한 로직으로 인해 발생하는 문제이다. 미리 예측하여 처리할 수 있기 때문에 올바른 처리방법을 통해 핸들링하는 것이 중요하다.
위 코드에 빨간줄이 아주 많다; 빨간줄이 나타나는 이유는 예외처리를 하지 않아서인데, 이처럼 예외처리를 꼭 해줘야하는 것들이 있다. 이러한 예외들을 CheckedException이라고 한다. 말 그대로 컴파일 시점에서 체크해주는 예외이다.
런타임 시점에 발생하는 예외들도 있는데 이는 UnCheckedException이라고도 하고 RuntimException이라고 한다. 이러한 예외는 컴파일 시점에 체크되지 않아 위 소스처럼 에러가 뜨지 않는다.
4. try, catch, finally
예외를 처리하기 위해서 사용하는 기본적인 문법이 있다. 바로 try, catch, finally이다.
try는 예외 발생 가능성이 있는 로직이 포함된 블럭, catch는 예외가 발생했을 때 처리되는 로직이 포함된 블럭, finally는 예외가 발생하던 안하던 최종적으로 처리되는 로직이 포함된 블럭이다.
간단한 예제를 통해 실습해보자.
예외 멈춰!
예외 멈춰! 결과
현재 File 객체의 매개변수 값으로 텍스트파일의 경로를 넣어놨는데, 이 경로는 실제로 존재하지 않는 파일의 경로이다. 이로인해 try 문 안의 fis = new FileInputStream 부분에서 FileNotFoundException (FileNotFoundException 예외는 Exception을 상속하고 있음) 이 발생하게 되는데, 이때 catch 블록으로 이동하여 예외 처리 후, 최종적으로 finally문에서 스트림을 닫게 된다.
그럼 이런 의문이 들 수 있다.
Q : catch의 매개변수에 Exception을 넣으면 결론적으로 try 문에서 발생한 모든 예외들은 저 하나의 catch문에서 처리되는게 아닌가? 그럼 다양한 예외에 대한 핸들링하지 못하잖아?
맞다. 저렇게 무작정 Exception으로만 넣게되면, 모든 예외를 한곳에서 핸드링하는 격이기 때문에 상황에 맞게 예외를 분기해서 처리해야 한다. 한곳에서 처리하는 것이 효율적인 예외도 있겠지만, 예를 들어 로직에 SQLException과 FileNotFoundException 예외가 발생할 수 있는 상황이라면 각각의 예외에 대한 세부 로그를 남기는 등의 예외처리를 하면 좋지 않을까 싶다. (참고로 모든 예외를 Exception으로 통일한 프로젝트도 있었다.)
5. throw, throws
예외란 프로그래머가 작성한 로직에 의해 발생된다. 그렇다면 프로그래머가 예외를 발생시킬수도 있을까? 있다. 추가적으로 예외에 대한 책임을 전가할수도 있다. 이게 바로 throw와 throws이다.
- throw는 예외를 강제로 발생시킨 후, 상위 블럭이나 catch문으로 예외를 던진다.
throw
위 예제는 main 메서드에서 myException메서드를 호출하고, 여기서 throw를 통해 Exception을 강제로 발생시키고 있다.
때문에 catch 블럭으로 처리가 위임되고, 여기서 예외를 처리하고 있다. 이는 콘솔 로그를 통해 알수있다.
- throws는 예외가 발생하면 상위메서드로 예외를 던진다.
throws
일반적으로 throws를 사용하면 try, catch 구문이 생성되지 않는 것을 확인할 수 있는데, 이 이유는 throws구문에 의해 예외에 대한 처리를 호출부로 위임하기 때문이다.
throw를 통해 예외를 발생시키고 throws는 이 예외를 밖으로 던져버리고 있다.
추가적으로 이 두가지를 합친 방식도 있다.
throw + throws는 예외처리를 catch문에서도 하고, 호출부로 예외를 던진다.
throw + throws
22줄에 throw e를 통해 예외를 발생시키면 throws에 의해 상위 메서드로 예외를 던지게 된다.
결과적으로 스프링 시큐리티 관련 bean은 rootApplicationContext에, sqlSession bean은 WebApplicationContext에 설정되었으며, 스프링 시큐리티 서비스 객체(rootApplicationContext)에서 sqlSession(WebApplicationContext)를 Autowired 하지 못해 발생한 문제였다.
ContextLoaderListener 설정으로 인해 의존 주입이 되지 않아 발생한 에러임을 확인하고 ContextLoaderListener에 대해 포스팅하려고 했으나, 오히려 이 부분에 대한 설명이 적은 것 같아 아쉽다. ㅠㅠ
서버에서 API 통신이나 HTTP 통신에 대한 응답 값으로 Json 형식의 문자열 데이터가 오는 경우가 있다. 이때 데이터의 특정 key에 해당하는 값에 접근하기 위해 String 클래스에서 제공하는 메서드를 사용할 수도 있으나, 데이터가 복잡해지고, Node 가 많아질 수록 데이터 조작 및 접근에 한계를 느끼게 된다.
이를 해소할 수 있는 방안으로 문자열 데이터를 JsonObject로 변환하는 방식이 있다. 이를 사용해보자.
교재를 보며 스프링 부트 환경에서 MVC 패턴을 사용하여 통신 테스트를 하던 도중 예기치 못한 상황이 발생했다.
Controller에서 String 형태로 View의 이름을 반환하려 했으나, 실제 반환된 것은 뷰가 아닌 스트링 자체였다.
test 를 리턴했을 때 test.html 리소스가 반환되는 것이 아닌 test 문자열 자체가 반환된 것이다. 코드를 확인해 보니 이 두 어노테이션을 적절히 사용하지 못해 발생한 문제였다.
2. @Controller
Controller 어노테이션을 사용 시 일반적으로 View Resolver에 설정한 값 기준으로 return 하는 값과 일치하는 View 를 찾아 반환한다. @ResponseBody어노테이션을 사용할 시 데이터 자체를 반환할 수 있으며, JSON 또는 String 형태로 값을 반환할 수 있다.
3. @RestController
@Controller + @ResponseBody 이다. 해당 컨트롤러에서 View를 리턴하지 않고, REST API를 사용한다면 이 설정이 적절하다.
만약 Controller 통신 후 view 페이지를 예상했는데 view 이름만 달랑 있는 페이지가 나오거나, 반대 상황이 나온다면 컨트롤러의 어노테이션을 확인해보자.
JUnit 을 사용하는 테스트 클래스에는 RunWith, ContextConfiguration 어노테이션이 붙는다. 책에서 RunWith는 스프링와 JUnit 간 인터페이스 역할을, ContextConfiguration은 스프링 컨텍스트 설정파일을 읽는 역할을 한다고 하나 크게 와닿지 않았다.
이런 마음을 갖고 공부를 하던 중 저 의미를 이해하게 되어 글을 남긴다.
2. @RunWith
RunWith(SpringJUnit4ClassRunner.class)는 말 그대로 SpringJUnit4ClassRunner.class를 실행한다는 것이고, 이 클래스는 내부적으로 스프링 컨테이너를 생성해준다.
3. @ContextConfiguration
생성된 스프링 컨테이너에 스프링 빈을 추가하기 위해서는 application-context.xml 파일과 같은 설정 파일을 읽어야 하는데, 이런 설정파일을 로드하는 어노테이션이 ContextConfiguration이다.
만약 스프링 컨테이너가 필요 없다면, 즉, 스프링 빈 팩토리에서 빈을 로드하는 것이 아닌, 직접 new로 객체를 생성해가며 테스트 코드를 작성할 것이라면 위의 어노테이션을 제거해도 된다.
실무 투입한지 거의 1년이 다 되어갈 무렵, web.xml 코드를 보던 중 문득 이런 생각이 들었다.
'웹 애플리케이션의 첫 단추인 web.xml에 대해 누군가에게 설명할 수 있을까?'
1년간 일은 열심히 했는데 가장 기본적인것에 대한 공부가 전혀 안되있음을 느껴, 공부 후 포스팅을 한다.
참고로 web.xml에 대한 예제는 MVC 패턴 기준으로 작성했다.
2. 정의
web.xml은 DD (Deployment Descriptor : 배포 설명자)라고 불리며, Web Application의 설정파일이다.
DD는 Web Application 실행 시 메모리에 로드된다.
즉, web.xml이란 웹 어플리케이션을 실행시킬 때 함께 올라가야할 설정(설명)들을 정의해놓은 것이다.
그렇다면 web.xml에는 어떤 설정을 할까?
3. 설정
Web.xml 에서는 크게DispatcherServlet, ContextLoaderListener, Filter설정을 한다.
클라이언트의 요청을 처리하는 DispatcherServlet.
웹 어플리케이션 컨텍스트 단위의 설정을 로드하는 ContextLoaderListener,
이건 꼭 거쳤으면 좋겠네. Filter.
3.1) DispatcherServlet
DispatcherServlet은 클라이언트의 요청을 전달받는 객체이다. 하는 일은? 당연히 클라이언트의 요청을 처리하는 일이다. 그럼 어떻게 처리할까?
클라이언트의 요청을 처리하려면 크게 4가지 일이 진행되어야 한다.
첫째, 클라이언트의 요청을 처리해줄 컨트롤러를 찾는다.
둘째, 컨트롤러를 실행시킨다. (비지니스 로직 처리)
셋째, 클라이언트에게 보여질 View를 찾는다.
넷째, 응답 데이터와 View를 클라이언트에게 전달한다.
요청을 처리할 컨트롤러를 찾는 일은Handler Mapping이라는 객체가 처리한다. 이 객체는 클라이언트의 요청 경로를 이용해서 컨트롤러를 검색하고, 검색된 객체를 DispatcherServlet에게 리턴한다.
만약 클라이언트가 'http://~~/test' 를 요청할 경우 /test를 처리할 컨트롤러 객체를 리턴하는 것이다.
컨트롤러를 실행시키는 일은 Handler Adapter라는 객체가 처리한다. 이 객체는 @Controller 어노테이션을 이용해 구현한 컨트롤러 뿐만 아니라, Controller 인터페이스를 구현한 컨트롤러, 특수 목적으로 사용되는 HttpRequestHandler 인터페이스를 구현한 클래스를 동일한 방식으로 실행할 수 있도록 만들어졌다. (출처 : 스프링5 입문. 최범균)
즉, 컨트롤러 실행 업무에 특화된 객체로 Controller를 실행하는 것이다.
Controller가 실행되면 개발자가 구현한 비지니스 로직을 거쳐 응답 데이터가 추출된다. 실행된 Controller는 리턴할 데이터와 View를 Handler Adapter에게 리턴한다.
Handler Adapter는 데이터와 view를 ModelAndView 형태로 DispatcherServlet에게 리턴한다.
여기서 view는 단순히 view의 이름이다. 뭔 소리냐면 이 이름에 해당하는 실제 view를 찾아야한다는 것이다.
만약 Controller에서 리턴한 view 이름이 hello였다면 /WEB-INF/view/hello.jsp를 찾아 dispatcher Servlet에게 리턴한다.
최종적으로 viewResolver가 리턴한 View 객체에 응답 데이터를 넣어 클라이언트에게 리턴한다.
이처럼 클라이언트의 요청은 DispatcherServlet라는 감독관(?)이 처리한다. 다만 직접 처리하지 않고 적절한 객체들에게 일을 위임하여 처리하고 있다.
3.2) ContextLoaderListener
앞서 Dispatcher Servlet은 클라이언트의 요청을 처리하는 객체라고 설명했다. 웹 어플리케이션의 규모가 커진다면, 클라이언트의 요청또한 다양해질 것이고, 이를 처리할 Dispatcher Servlet도 늘어날 가능성이 있다. 다른 성격을 가진 서블릿이 생성될 것이고, 설정 또한 서블릿의 성격에 맞게 각각 적용시켜야 한다.
반면에, 모든 서블릿이 공통으로 가져야할 설정들도 있다. 즉 Servlet Context 단위가 아닌 Application Context 단위의 설정이 필요한데 이를 ContextLoaderListener 객체가 처리한다.
이 객체는 Application Context 단위의 설정을 생성한다.
참고로 Application Context 는 Web Application 의 Context이며, 모든 Servlet들이 참조가 가능한 부모 Context이다.
3.3) Filter
클라이언트에서 온 요청을 Dispatcher Servlet이 받기 전 거치는 부분이 있다. 바로 이 Filter 객체이다.
만약 스프링 시큐리티 필터가 적용되어 있다면, 인가 및 인증 처리를 먼저 처리하고, 인코딩 필터가 적용되어 있다면 클라이언트의 요청데이터를 인코딩하는 작업이 선 처리된 후 Dispatcher Servlet에게 필터링 된 데이터가 전달된다.
4. 예제
이제 나같은 코린이가 흔히 봤던... 그저 작성만 했던... web.xml 코드를 분석해보자
셋째, web.xml에는 크게 dispatcherServlet, contextLoaderListener, filter 를 설정한다.
만약 tomcat이라는 WAS(Web Application Server)를 통해 이 web Application을 실행시킨다고 가정하면, web.xml 파일에 설정한 내용들이 메모리에 로드될 것이다.
본격적으로 코드를 분석해보자.
7 ~ 16 line - 클라이언트의 요청을 처리하는 Dispatcher Servlet을 myDispatcherServlet이란 이름으로 생성하고, 이 서블릿에 대한 설정파일로 servlet-config.xml을 지정한다. (controller 스캔용, 코드는 글의 최하단에 첨부)
17 ~ 20 line - 설정한 Dispatcher Servlet이 처리할 url-pattern을 설정한다. '/' 경로로 들어오는 모든 요청에 대해서 myDispatcherServlet이 처리를 담당한다.
23 ~ 31 line - web application context 단위의 설정파일로 application-context.xml을 설정한다. 이 설정은 servelt으로 생성한 myDispatcherServlet에게 공유된다. (view-resolver 설정용, 코드는 글의 최하단에 첨부)
34 ~ 47 line - 스프링에서 지원하는 encoding Filter를 filter에 추가한다.
48 ~ 51 line - encoding Filter가 처리할 url-pattern을 설정한다. '/*' 모든 경로에 대해 인코딩 필터를 적용한다.
정리하면 이 예제 web.xml은 클라이언트의 요청을 처리할 인코딩 필터와 Dispatcher Servelt을 생성하고, view Resolver를 web application context 단위로 설정하였다.
3번 줄의 configuration status 구문은 이 설정파일이 로드될 때 발생하는 로그에 대한 레벨을 설정하는 부분이다.
말이 어렵지 실행화면을 보면 이해가 갈것이다.
configuration status = "DEBUG"
log4j2.xml 의 내부 설정을 로드하면서 발생하는 DEBUG 이상의 로그들을 출력중이다.
status를 info로 설정하면 아~~~무 로그도 출력되지 않는다.
그 이유는 log4j2.xml 설정파일을 로드할 때의 정보는 내부적으로 DEBUG레벨로 찍고 있기 때문이다.
INFO 레벨은 DEBUG레벨보다 상위의 레벨이기 때문에 로그가 찍히지 않게 된다.
그렇다면 log4j2.xml 파일을 로드할 때 문제가 생기도록 코드를 바꾼 후 status를 info로 설정한다면?
내부적으로 error 로그가 발생할 것이고, 이는 info 레벨보다 높기 때문에 로그가 찍힐 것이다.
테스트로 5번줄의 Appenders 태그 명을 Appenderss로 바꾼 후 실행시켰다.
제일 아랫줄의 ERROR test.LogTest 부분이 log4j2.xml 을 로드하면서 생긴에러이다.
configuration status ="info" And Appenders -> Appenderss
* configuration 부분을 설명하기 위해 먼저 MainClass와 LogTest를 구현하였다. 현재 MainClass와 LogTest 를 생성만 한 상태에서는 위처럼 테스트가 불가능하다. 이런 설정이구나 라고만 이해하고 넘어가자.
Appenders 태그 안에 실질적인 로그 설정 코드를 삽입한다.
현재 콘솔에 로그를 출력시키기 위해 <Console> 태그 관련 코드를 삽입하고 로그로 찍히는 패턴을 PatternLayout 태그를 통해 설정한다.
%d는 로그 시간에 관한 설정을 나타내는데 괄호 안의 형태로 포멧시킬 수 있다.
%p는 로그 레벨, %c는 로그가 발생한 클래스 경로, %m은 로그 메시지, %n은 개행이다.
%5p는 로그 레벨이 출력되는 기본 문자열 길이를 5로 설정한다는 의미이다.
WARN 앞에 공백 보이시죠?
12번 줄의 loggers 는 설정한 로그 코드를 적용하는 부분이다.
root 태그를 사용하면 현재 시스템에서 발생하는 모든 로그를 찍어낼 수 있고, level을 debug로 설정하여 debug 이상의 로그만 출력되도록 한다. Appender를 이용해서 앞서 설정한 console을 적용시키면, 결과적으로 기동하는 시스템내에서 발생하는 모든 로그 중 debug레벨 이상은 모두 찍히게 된다.
