서블릿은 2가지 방식으로 예외를 처리한다.1\. Exception(예외)2\. response.sendError(Http 상태 코드, 오류 메세지)자바의 경우 메인 메서드 실행의 경우 main이라는 이름의 쓰레드가 실행되는데, 예외가 발생하여 이를 잡지 못하면, 예외정
앞서 예외와 그 흐름에 대해서 알아보았다. 그 흐름은 아래와 같다.위와 같은 흐름으로 예외가 발생하면, WAS에서 에러 페이지를 다시 요청하는데 이 과정에서 필터, 인터셉터, 컨트롤러 등이 다시 호출이 된다.그런데 로그인 체크의 경우를 생각해보면 이미 로그인 체크를 끝
지난 포스팅에서 서블릿을 활용한 예외 처리 방법에 대해서 알아보았다.그런데 WebServerCustomizer를 생성하거나, 에러 페이지를 추가하고, 컨트롤러를 생성하는 등의 복잡한 과정이 필요했다. 이번에는 스프링부트를 활용하여 이 과정이 어떻게 생략되는지 확인해보자
지난 포스팅까지 해서 HTML을 반환하는 예외 처리 방법에 대해서 알아보았다. 그런데 그 방법처럼 예외로서 HTML을 반환하면 어떻게 될까? 코드로 결과를 확인해보자우선 지난번에 생성했던 에러페이지를 등록하는 클래스를 빈으로 등록해주자코드는 바뀐 것이 없고 @Compo
HTML예외 처리를 생각해보자. 로그인 기능의 문제이든, 게시판 업로드 기능의 문제이든 HTML 예외 처리의 경우 4XX, 5XX의 경우만 생각하고, 그에 맞는 예외 페이지만 띄워주면 된다.하지만 API의 경우는?API의 경우 HTML문서를 반환하는 것이 아니라, 각
예외가 발생했는데, 예외를 처리하지 못한다면 예외가 WAS까지 전달이 되고, WAS에서는 다시 에러 페이지 정보를 찾아서 요청을 호출하는 복잡한 과정이 일어나게 된다.그런데 이전의 포스팅에서 알아보았던 ExceptionResolver를 활용하면 이런 과정 없이 Hand
지난 포스팅에서 HandlerExceptionResolver를 직접 구현하여 API예외를 처리하는 방법에 대해서 알아보았다. HandlerExceptionResolver를 활용하면 컨트롤러 밖으로 던져진 예외를 처리해 WAS에서 에러 페이지를 재요청하는 복잡한 과정을
지난 포스팅에서 자바 예외처리에 대해 알아보았다. 이번 포스팅에서는 인터페이스 활용에 있어서 체크 예외와 언체크 예외에 따라 어떻게 바뀌는지 알아보고자 한다.인터페이스에 예외가 선언되어 있다.구현체에서도 SQLException을 던지고 있다.그렇다면 Repository
지난 포스팅까지 해서 자바 예외와, 스프링에서 직접 예외 클래스를 생성해 순수 서비스 로직을 유지하는 방법까지 알아보았다. 그런데 예외가 발생했을 때 서비스 로직에서 뭔가 복구를 시도해보려고 한다면 DB 종류에 따라 여러 로직을 작성해야 한다. 한 가지 예를 들어보자