'분류 전체보기' 카테고리의 글 목록 (68 Page)

분류 전체보기에 해당되는 글 281건

2022.07.16 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17
2022.07.16 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16
2022.07.16 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17

Spring 정리 2022. 7. 16. 22:46

인프런 강의 55일차.

- 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 1 (김영한 강사님)

- 1편에서 배운 MVC를 활용할 수 있는 기술 습득

- 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

9.1 API 예외 처리 - 시작

- API 예외 처리는 어떻게 해야할까

- HTML 페이지의 경우 지금까지 설명했던 것 처럼 4xx, 5xx와 같은 오류 페이지만 있으면 대부분의 문제를 해결할 수 있다.

- 그런데 API의 경우에는 생각할 내용이 더 많다.

- 오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.

- 지금부터 API의 경우 어떻게 예외 처리를 하면 좋은지 알아보자.

- API도 오류 페이지에서 설명했던 것 처럼 처음으로 돌아가서 서블릿 오류 페이지로 방식을 사용해보자

package hello.exception;

import org.springframework.boot.web.server.ConfigurableWebServerFactory;
import org.springframework.boot.web.server.ErrorPage;
import org.springframework.boot.web.server.WebServerFactoryCustomizer;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        //Springboot에서 제공해주는 ErrorPage 클래스는 사용해 에러 정의
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");

        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);     //에러 페이지 등록
    }
}

- hello.exception.WebServerCustomizer.java

- WebServerCustomizer 가 다시 사용되도록 하기 위해 @Component 애노테이션에 적용한 주석을 풀자

- 이제 WAS에 예외가 전달되거나, response.sendError() 가 호출되면 위에 등록한 예외 페이지 경로가 호출된다

package hello.exception.api;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@Slf4j
@RestController
public class ApiExceptionController {


    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if(id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        return new MemberDto(id, "hello " + id);
    }


    @Data
    @AllArgsConstructor
    static class MemberDto {
        private String memberId;
        private String name;
    }
}

- hello.exception.api.ApiExceptionController.java

- 회원을 조회하는 기능을 만들고, 예외 테스트를 위해 URL에 전달된 id 의 값이 ex 이면 예외가 발생하도록 구현.

* 정상 호출 시 응답

{
    "memberId": "spring",
    "name": "hello spring"
}

- Postman으로 테스트

- HTTP Header에 Accept 가 application/json으로 날려야 JSON으로 날아간다는 것을 주의

- API를 요청했는데, 정상의 경우 API로 JSON 형식으로 데이터가 정상 반환된다.

* 예외 발생 오류 호출 시 응답

<!DOCTYPE HTML>
<html>
    <head>
    </head>
    <body>
    ...
    </body>
</html>

- 그런데 오류가 발생하면 우리가 미리 만들어둔 오류 페이지 HTML이 반환된다. 이것은 기대하는 바가 아니다.

- 클라이언트는 정상 요청이든, 오류 요청이든 JSON이 반환되기를 기대한다.

- 웹 브라우저가 아닌 이상 HTML을 직접 받아서 할 수 있는 것은 별로 없다.

- 오류 페이지 컨트롤러도 JSON 응답을 할 수 있도록 수정해야 한다.

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
...

@Slf4j
@Controller
public class ErrorPageController {

	...
    //Client가 보내는 헤더 타입에 대해 자세하게 정의되어 있는 메소드를 먼저 호출한다.
    //application/json인 경우 같은 error-page/500이 호출되었을 때 produces에 APPLICATION_JSON_VALLUE 가 걸린 메소드가 먼저 호출된다.
    @RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Map<String, Object>> errorPage500Api (HttpServletRequest request, HttpServletResponse response) {
        log.info("API errorPage 500");

        HashMap<String, Object> result = new HashMap<>();
        Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);;

        result.put("status", request.getAttribute(ERROR_STATUS_CODE));
        result.put("message", ex.getMessage());

        Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);

        return  new ResponseEntity<>(result, HttpStatus.valueOf(statusCode));
    }
    ...
}

- hello.exception.servlet.ErrorPageController.java

- produces = MediaType.APPLICATION_JSON_VALUE 의 뜻은 클라이언트가 요청하는 HTTP Header의 Accept 의 값이 application/json 일 때 해당 메소드가 호출된다는 것이다.

> 결국 클라어인트가 받고 싶은 미디어타입이 json이면 이 컨트롤러의 메소드가 호출된다.

- 응답 데이터를 위해서 HashMap 을 만들고 status, message 키에 값을 할당했다.

> Jackson 라이브러리는 Map 을 JSON 구조로 변환할 수 있다.

- ResponseEntity 를 사용해서 응답하기 때문에 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환된다

* APPLICATION_JSON_VALUE 추가 후 예외 발생 오류 호출 시 응답

{
    "message": "잘못된 사용자",
    "status": 500
}

- HTTP Header에 Accept 가 application/json 이 아니면, 기존 오류 응답인 HTML 응답이 출력되는 것을 확인할 수 있다

9.2 API 예외 처리 - 스프링 부트 기본 오류 처리

- API 예외 처리도 스프링 부트가 제공하는 기본 오류 방식을 사용할 수 있다.

@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {
   HttpStatus status = getStatus(request);
   Map<String, Object> model = Collections
         .unmodifiableMap(getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.TEXT_HTML)));
   response.setStatus(status.value());
   ModelAndView modelAndView = resolveErrorView(request, response, status, model);
   return (modelAndView != null) ? modelAndView : new ModelAndView("error", model);
}

@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {
   HttpStatus status = getStatus(request);
   if (status == HttpStatus.NO_CONTENT) {
      return new ResponseEntity<>(status);
   }
   Map<String, Object> body = getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.ALL));
   return new ResponseEntity<>(body, status);
}

- 스프링부트에서 제공하는 BasicErrorController.java

- /error 동일한 경로를 처리하는 errorHtml() , error() 두 메서드를 확인할 수 있다

- errorHtml() : produces = MediaType.TEXT_HTML_VALUE이므로 클라이언트 요청의 Accept 헤더 값이 text/html 인 경우에는 errorHtml() 을 호출해서 view를 제공한다.

- error() : 그외 경우에 호출되고 ResponseEntity 로 HTTP Body에 JSON 데이터를 반환한다.

* 스프링 부트의 예외 처리

- 스프링 부트의 기본 설정은 오류 발생시 /error 를 오류 페이지로 요청한다.

- BasicErrorController 는 이 경로를 기본으로 받는다. ( server.error.path 로 수정 가능, 기본 경로 / error )

- BasicErrorController 를 사용하도록 WebServerCustomizer 의 @Component 를 주석처리 하자

> WebServerCustomizer 은 서블릿에서 제공하는 예외처리

{
    "timestamp": "2022-07-16T00:00:00.000+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.RuntimeException",
    "trace": "java.lang.RuntimeException: 잘못된 사용자\n\tat
    hello.exception.web.api.ApiExceptionController.getMember(ApiExceptionController.java:19...,
    "message": "잘못된 사용자",
    "path": "/api/members/ex"
}

- 스프링 부트는 BasicErrorController 가 제공하는 기본 정보들을 활용해서 오류 API를 생성해준다

* Html 페이지 vs API 오류

- BasicErrorController 를 확장하면 JSON 메시지도 변경할 수 있다. 그런데 API 오류는 조금 뒤에 설명할 @ExceptionHandler 가 제공하는 기능을 사용하는 것이 더 나은 방법이므로 지금은 BasicErrorController 를 확장해서 JSON 오류 메시지를 변경해보자.

- 스프링 부트가 제공하는 BasicErrorController 는 HTML 페이지를 제공하는 경우에는 매우 편리하다.

- 4xx, 5xx 등등 모두 잘 처리해준다. 그런데 API 오류 처리는 다른 차원의 이야기이다.

- API 마다, 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있다.

> 예를 들어서 회원과 관련된 API에서 예외가 발생할 때 응답과, 상품과 관련된 API에서 발생하는 예외에 따라 그 결과가 달라질 수 있다.

- 결과적으로 매우 세밀하고 복잡하다.

- 따라서 이 방법은 HTML 화면을 처리할 때 사용하고, API는 오류 처리는 뒤에서 설명할 @ExceptionHandler 를 사용하자

9.3 API 예외 처리 - HandlerExceptionResolver 시작

- 예외가 발생해서 서블릿을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리된다.

- 발생하는 예외에 따라서 400, 404 등등 다른 상태코드도 처리해보자,

- 오류 메시지, 형식등을 API마다 다르게 처리해보자.

- IllegalArgumentException 을 처리하지 못해서 컨트롤러 밖으로 넘어가는 일이 발생하면 HTTP 상태코드를 400으로 처리하고 싶다. 어떻게 해야할까?

...

@Slf4j
@RestController
public class ApiExceptionController {

    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        return new MemberDto(id, "hello " + id);
    }
	...
}

- hello.exception.api.ApiExceptionController.java

- /api/members/bad 호출 시 IllegalArgumentException이 발생하도록 처리했다.

* /api/members/bad 호출 결과

{
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.IllegalArgumentException",
    "path": "/api/members/bad"
}

- Http Status 500 에러가 발생함을 확인

* HandlerExceptionResolver

- 스프링 MVC는 컨트롤러(핸들러) 밖으로 예외가 던져진 경우 예외를 해결하고, 동작을 새로 정의할 수 있는 방법을 제공한다.

- 컨트롤러 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver 를 사용하면 된다. 줄여서 ExceptionResolver 라 한다

* ExceptionResolver 적용 전

* ExceptionResolver 적용 후

> ExceptionResolver 를 적용하기 전에도 컨트롤러에서 예외가 발생하면 postHandle()가 호출되지 않았다.

> ExceptionResolver 로 예외를 해결해도 postHandle() 은 호출되지 않는다

* HandlerExceptionResolver - 인터페이스

public interface HandlerExceptionResolver {
    ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response,Object handler, Exception ex);
}

- handler : 핸들러(컨트롤러) 정보

- Exception ex : 핸들러(컨트롤러)에서 발생한 발생한 예외

* MyHandlerExceptionResolver

package hello.exception.resolver;

import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ModelAndView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {

        log.info("resolveException --- ");
        try {
            if (ex instanceof IllegalArgumentException) {
                log.info("IllegalArgumentException resolver to 400");
                response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage());
                return new ModelAndView();
            }
        } catch (IOException e) {
            log.error("resolver ex ", e);
        }
        return null;        //null로 리턴 시 전달받은 예외가 그대로 전달됨
    }
}

- hello.exception.resolver.MyHandlerExceptionResolver.java

- ExceptionResolver 가 ModelAndView 를 반환하는 이유는 try, catch를 하듯이 Exception 을 처리해서 정상 흐름 처럼 변경하는 것이 목적이다. 이름 그대로 Exception 을 Resolver(해결)하는 것이 목적이다.

- 여기서는 IllegalArgumentException 이 발생하면 response.sendError(400) 를 호출해서 HTTP 상태 코드를 400으로 지정하고, 빈 ModelAndView 를 반환한다

* 반환 값에 따른 동작 방식

- HandlerExceptionResolver 의 반환 값에 따른 DispatcherServlet 의 동작 방식은 다음과 같다.

> 빈 ModelAndView : new ModelAndView() 처럼 빈 ModelAndView 를 반환하면 뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴된다.

> 특정 ModelAndView 지정 : ModelAndView 에 View , Model 등의 정보를 지정해서 반환하면 뷰를 렌더링 한다.

> null: null 을 반환하면, 다음 ExceptionResolver 를 찾아서 실행한다. 만약 처리할 수 있는 ExceptionResolver 가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던진다.

* ExceptionResolver 활용

- 예외 상태 코드 변환

> 예외를 response.sendError(xxx) 호출로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임

> 이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출, 예를 들어서 스프링 부트가 기본으로 설정한 / error 가 호출됨

- 뷰 템플릿 처리

> ModelAndView 에 값을 채워서 예외에 따른 새로운 오류 화면 뷰 렌더링 해서 고객에게 제공

- API 응답 처리

> response.getWriter().println("hello"); 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능하다.

> 여기에 JSON 으로 응답하면 API 응답 처리를 할 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
    }

    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        //내가 구현한 ExceptionResolver를 ExceptionHandler에 등록한다.
        resolvers.add(new MyHandlerExceptionResolver());
    }
	...
}

- hello.exception.WebConfig.java

- configureHandlerExceptionResolvers(..) 를 사용하면 스프링이 기본으로 등록하는 ExceptionResolver 가 제거되므로 주의,

> extendHandlerExceptionResolvers 를 사용하자

* Postman으로 실행

- http://localhost:8080/api/members/ex -> HTTP 상태 코드 500 반환

- http://localhost:8080/api/members/bad -> HTTP 상태 코드 400 반환

9.4 API 예외 처리 - HandlerExceptionResolver 활용

- 예외가 발생하면 WAS까지 던져지고, WAS에서 오류 페이지 정보를 찾아서 다시 /error 를 호출하는 과정은 복잡하다.

> ExceptionResolver 를 활용하면 예외가 발생했을 때 이런 복잡한 과정 없이 깔끔하게 해결할 수 있다.

package hello.exception.exception;

public class UserException extends RuntimeException {

    public UserException() {
        super();
    }

    public UserException(String message) {
        super(message);
    }

    public UserException(String message, Throwable cause) {
        super(message, cause);
    }

    public UserException(Throwable cause) {
        super(cause);
    }

    protected UserException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }
}

- hello.exception.exception.UserException.java

- RuntimeException을 오버라이드한 UserException 추가

...

@Slf4j
@RestController
public class ApiExceptionController {

    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        if (id.equals("user-ex")) {
            throw new UserException("사용자 오류");
        }
        return new MemberDto(id, "hello " + id);
    }
	...
}

- hello.exception.api.ApiExceptionController.java

- /api/members/user-ex 호출 시 UserException이 발생하도록 처리

- 이제 UserException을 처리하는 UserHandlerExceptionResolver를 만들어보자.

package hello.exception.resolver;

import com.fasterxml.jackson.databind.ObjectMapper;
import hello.exception.exception.UserException;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ModelAndView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

@Slf4j
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {

    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        try {
            if (ex instanceof UserException) {
                log.info("UserException resolver to 400");
                String acceptHeader = request.getHeader("accept");
                response.setStatus(HttpServletResponse.SC_BAD_REQUEST); //Https 상태코드 400으로 변경

                if ("application/json".equals(acceptHeader)) {
                    Map<String, Object> errorResult = new HashMap<>();
                    errorResult.put("ex", ex.getClass());
                    errorResult.put("message", ex.getMessage());

                    //errorResult를 objectMapper.writeValueAsString을 사용해 JSON 형태로 바꿔준다.
                    String result = objectMapper.writeValueAsString(errorResult);

                    response.setContentType("application/json");
                    response.setCharacterEncoding("utf-8");
                    response.getWriter().write(result);
                    return new ModelAndView();
                } else {
                    // TEXT/HTML
                    return new ModelAndView("error/500");
                }
            }
        } catch (IOException e) {
            log.error("resolver ex", e);
        }
        return null;
    }
}

- hello.exception.resolver.UserHandlerExceptionResolver.java

- HTTP 요청 해더의 ACCEPT 값이 application/json 이면 JSON으로 오류를 내려주고, 그 외 경우에는 error/500에 있는 HTML 오류 페이지를 보여준다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
	...
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        //내가 구현한 ExceptionResolver를 ExceptionHandler에 등록한다.
        resolvers.add(new MyHandlerExceptionResolver());
        resolvers.add(new UserHandlerExceptionResolver());
    }
    ...
}

- 내가 만든 UserHandlerExceptionResolver를 핸들러에 등록

* /api/members/user-ex 호출 결과

//Accept : application/json 인 경우 JSON 으로 리턴
{
    "ex": "hello.exception.exception.UserException",
    "message": "사용자 오류"
}

//Accept : text/html 인 경우 HTML 코드 리턴
<!DOCTYPE HTML>
<html>
...
</html>

* 정리

- ExceptionResolver 를 사용하면 컨트롤러에서 예외가 발생해도 ExceptionResolver 에서 예외를 처리해버린다.

- 따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고, 스프링 MVC에서 예외 처리는 끝이 난다.

- 결과적으로 WAS 입장에서는 정상 처리가 된 것이다.

> 예외를 이곳에서 모두 처리할 수 있다는 것이 핵심이다

- 서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다.

- 반면에 ExceptionResolver 를 사용하면 예외처리가 상당히 깔끔해진다.

- 그런데 직접 ExceptionResolver 를 구현하려고 하니 상당히 복잡하다.

> 스프링이 제공하는 ExceptionResolver 들을 알아보자.

9.5 API 예외 처리 - 스프링이 제공하는 ExceptionResolver1

- 스프링 부트가 기본으로 제공하는 ExceptionResolver 는 다음과 같다.

* HandlerExceptionResolverComposite 에 3개가 순서대로 등록된다.

1. ExceptionHandlerExceptionResolver

- @ExceptionHandler 을 처리한다. API 예외 처리는 대부분 이 기능으로 해결한다.

2. ResponseStatusExceptionResolver

- HTTP 상태 코드를 지정해준다.

- @ResponseStatus(value = HttpStatus.NOT_FOUND)

3. DefaultHandlerExceptionResolver (우선 순위가 가장 낮다)

- 스프링 내부 기본 예외를 처리한다.

* ResponseStatusExceptionResolver

- ResponseStatusExceptionResolver 는 예외에 따라서 HTTP 상태 코드를 지정해주는 역할을 한다

> @ResponseStatus 가 달려있는 예외

> ResponseStatusException 예외

package hello.exception.exception;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
public class BadRequestException extends RuntimeException {
}

- hello.exception.exception.BadRequestException.java

- 예외에 @ResponseStatus 애노테이션을 적용하면 HTTP 상태 코드를 변경해준다.

- BadRequestException 예외가 컨트롤러 밖으로 넘어가면 ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 담는다

- ResponseStatusExceptionResolver 코드를 확인해보면 결국 response.sendError(statusCode, resolvedReason) 를 호출하는 것을 확인할 수 있다.

> sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/response-status-ex1")
    public String responseStatusEx1() {
        throw new BadRequestException();
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- @ResponseStatus 를 테스트하기 위한 responseStatusEx1 메소드 추가

* /api/response-status-ex1 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류",
    "path": "/api/response-status-ex1"
}

- @ResponseStatus에 정의한 것 처럼 status 코드는 400으로, message는 "잘못된 요청 오류"로 변경되었다.

* 메시지 기능

- @ResponseStatus에 사용한 reason 을 MessageSource 에서 찾는 기능도 제공한다.

> reason = "error.bad" 으로 사용

error.bad=잘못된 요청 오류입니다. 메시지 사용

- message.properties 에 error.bad 값정의

* 메시지 기능 사용한 /api/response-status-ex1 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류",
    "path": "/api/response-status-ex1"
}

* ResponseStatusException

- @ResponseStatus 는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다.

> 애노테이션을 직접 넣어야 하는데, 내가 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에는 적용할 수 없다.

- 추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어렵다.

- 이때는 ResponseStatusException 예외를 사용하면 된다.

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/response-status-ex2")
    public String responseStatusEx2() {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- 조건에 따라 동적으로 변동되는 에러를 처리하기 위해 ResponseStatusException을 구현한 responseStatusEx2 메소드

* /api/response-status-ex2 호출 결과

{
    "status": 404,
    "error": "Not Found",
    "exception": "org.springframework.web.server.ResponseStatusException",
    "message": "잘못된 요청 오류입니다. 메시지 사용",
    "path": "/api/response-status-ex2"
}

9.6 API 예외 처리 - 스프링이 제공하는 ExceptionResolver2

- DefaultHandlerExceptionResolver 를 살펴보자

- DefaultHandlerExceptionResolver 는 스프링 내부에서 발생하는 스프링 예외를 해결한다.

- 대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생하는데, 이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생한다.

- 그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제이다.

- HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있다.

> DefaultHandlerExceptionResolver 는 이것을 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경한다.

- 스프링 내부 오류를 어떻게 처리할지 수 많은 내용이 정의되어 있다

* 코드 확인

- DefaultHandlerExceptionResolver.handleTypeMismatch 를 보면 코드를 확인할 수 있다.

- response.sendError(HttpServletResponse.SC_BAD_REQUEST) (400)

> 결국 response.sendError() 를 통해서 문제를 해결한다.

> sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/default-handler-ex")
    public String defaultException(@RequestParam Integer data) {
    	return "ok";
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- Integer data 에 문자를 입력하면 내부에서 TypeMismatchException 이 발생한다.

* /api/default-handler-ex?data=hello&message= 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "org.springframework.web.method.annotation.MethodArgumentTypeMismatchException",
    "message": "Failed to convert value of type 'java.lang.String' to required type 'java.lang.Integer'; nested exception is java.lang.NumberFormatException: For input string: \"hello\"",
    "path": "/api/default-handler-ex"
}

- 실행 결과를 보면 TypeMismatchException이고 HTTP 상태 코드가 400인 것을 확인할 수 있다

* 정리

- 지금까지 HTTP 상태 코드를 변경하고, 스프링 내부 예외의 상태코드를 변경하는 기능도 알아보았다.

- 그런데 HandlerExceptionResolver 를 직접 사용하기는 복잡하다.

- API 오류 응답의 경우 response 에 직접 데이터를 넣어야 해서 매우 불편하고 번거롭다.

- ModelAndView 를 반환해야 하는 것도 API에는 잘 맞지 않는다.

- 스프링은 이 문제를 해결하기 위해 @ExceptionHandler 라는 매우 혁신적인 예외 처리 기능을 제공한다.

'Spring 정리' 카테고리의 다른 글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 19 (0)	2022.07.20
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 18 (0)	2022.07.19
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 14 (0)	2022.07.10

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16

Spring 정리 2022. 7. 16. 18:33

인프런 강의 54일차.

- 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 1 (김영한 강사님)

- 1편에서 배운 MVC를 활용할 수 있는 기술 습득

- 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

8.4 예외 처리와 오류 페이지 - 서블릿 예외 처리 - 오류 페이지 작동 원리

- 서블릿은 Exception (예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError() 가 호출 되었을 때 설정된 오류 페이지를 찾는다.

- WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.

> new ErrorPage(RuntimeException.class, "/error-page/500")

- RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.

- 확인해보니 RuntimeException 의 오류 페이지로 /error-page/500 이 지정되어 있다.

- WAS는 오류 페이지를 출력하기 위해 /error-page/500 를 다시 요청한다

- 중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다는 점이다.

- 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.

* 흐름 정리

- 예외가 발생해서 WAS까지 전파된다.

- WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다.

> 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

- WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request 의 attribute 에 추가해서 넘겨준다.

- 필요하면 오류 페이지에서 이렇게 전달된 오류 정보를 사용할 수 있다

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Slf4j
@Controller
public class ErrorPageController {

    //RequestDispatcher 상수로 정의되어 있음
    public static final String ERROR_EXCEPTION = "javax.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE = "javax.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "javax.servlet.error.message";
    public static final String ERROR_REQUEST_URI = "javax.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME = "javax.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE = "javax.servlet.error.status_code";

    @RequestMapping("/error-page/404")
    public String errorPage404 (HttpServletRequest request, HttpServletResponse response) {
        log.info("errorPage 404");
        return "error-page/404";
    }

    @RequestMapping("/error-page/500")
    public String errorPage500 (HttpServletRequest request, HttpServletResponse response) {
        log.info("errorPage 500");
        return "error-page/500";
    }

    private void printErrorInfo(HttpServletRequest request) {
        log.info("ERROR_EXCEPTION: ex=", request.getAttribute(ERROR_EXCEPTION));
        log.info("ERROR_EXCEPTION_TYPE: {}", request.getAttribute(ERROR_EXCEPTION_TYPE));
        log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE)); //ex의 경우 NestedServletException 스프링이 한번 감싸서 반환
        log.info("ERROR_REQUEST_URI: {}", request.getAttribute(ERROR_REQUEST_URI));
        log.info("ERROR_SERVLET_NAME: {}", request.getAttribute(ERROR_SERVLET_NAME));
        log.info("ERROR_STATUS_CODE: {}", request.getAttribute(ERROR_STATUS_CODE));
        log.info("dispatchType={}", request.getDispatcherType());
    }
}

- hello.exception.servlet.ErrorPageController.java

- 에러 로그 출력 추가

- request.attribute에 서버가 담아준 정보

> javax.servlet.error.exception : 예외

> javax.servlet.error.exception_type : 예외 타입

> javax.servlet.error.message : 오류 메시지

> javax.servlet.error.request_uri : 클라이언트 요청

> URI javax.servlet.error.servlet_name : 오류가 발생한 서블릿 이름

> javax.servlet.error.status_code : HTTP 상태 코드

8.5 예외 처리와 오류 페이지 - 서블릿 예외 처리 - 필터

- 예외 처리에 따른 필터와 인터셉터 그리고 서블릿이 제공하는 DispatchType 이해하기

- 오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생한다.

- 이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다. 그런데 로그인 인증 체크 같은 경우를 생각해보면, 이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했다.

- 따라서 서버 내부에서 오류 페이지를 호출한다고 해서 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다.

- 결국 클라이언트로 부터 발생한 정상 요청인지, 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다.

> 서블릿은 이런 문제를 해결하기 위해 DispatcherType 이라는 추가 정보를 제공한다

* DispatcherType

- 필터는 이런 경우를 위해서 dispatcherTypes 라는 옵션을 제공한다.

- log.info("dispatchType={}", request.getDispatcherType())를 출력해보면 오류 페이지에서 dispatchType=ERROR 로 나오는 것을 확인할 수 있다. (고객이 처음 요청하면 dispatcherType=REQUEST 이다.)

- 서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지 DispatcherType 으로 구분할 수 있는 방법을 제공한다.

public enum DispatcherType {
    FORWARD,
    INCLUDE,
    REQUEST,
    ASYNC,
    ERROR
}

- REQUEST : 클라이언트 요청

- ERROR : 오류 요청

- FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때

> RequestDispatcher.forward(request, response);

- INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때

> RequestDispatcher.include(request, response);

- ASYNC : 서블릿 비동기 호출

* LogFilter - DispatcherType 로그 추가

package hello.exception.filter;
import lombok.extern.slf4j.Slf4j;
import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;
import java.util.UUID;

@Slf4j
public class LogFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        log.info("log filter init");
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();
        String uuid = UUID.randomUUID().toString();

        try {
            log.info("REQUEST [{}][{}][{}]", uuid, request.getDispatcherType(), requestURI);
            chain.doFilter(request, response);
        } catch (Exception e) {
            throw e;
        } finally {
            log.info("RESPONSE [{}][{}][{}]", uuid, request.getDispatcherType(), requestURI);
        }
    }

    @Override
    public void destroy() {
        log.info("log filter destroy");
    }
}

- hello.exception.filter.LogFilter.java

- 로그를 출력하는 부분에 request.getDispatcherType() 을 추가

package hello.exception;
import hello.exception.filter.LogFilter;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;


@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public FilterRegistrationBean logFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();

        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");

        /*
        REQUEST, ERROR 두 가지를 모두 넣으면 클라이언트 요청은 물론이고, 오류 페이지 요청에서도 필터가 호출된다
        아무것도 넣지 않으면 기본 값이 DispatcherType.REQUEST 이다.
        즉 클라이언트의 요청이 있는 경우에만 필터가 적용된다. 
        특별히 오류 페이지 경로도 필터를 적용할 것이 아니면, 기본 값을 그대로 사용하면 된다.
         */
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

        return filterRegistrationBean;
    }
}

- hello.exception.WebConfig.java

- filterRegistrationBean.setDispatcherType으로 dispatchType 별 필터를 지정할 수 있다.

- 오류 페이지 요청 전용 필터를 적용하고 싶으면 DispatcherType.ERROR 만 지정하면 된다

- 필터는 기본 default가 DispatcherType.REQUEST이므로 오류가 나도 별다른 문제가 없음을 알 수 있다.

8.6 예외 처리와 오류 페이지 - 서블릿 예외 처리 - 인터셉터

- 필터의 경우에는 필터를 등록할 때 어떤 DispatcherType 인 경우에 필터를 적용할 지 선택할 수 있었다.

- 인터셉터는 서블릿이 제공하는 기능이 아니라 스프링이 제공하는 기능이다.

- 따라서 DispatcherType 과 무관하게 항상 호출된다.

- 대신에 인터셉터는 요청 경로에 따라서 추가하거나 제외하기 쉽게 되어 있기 때문에, 이러한 설정을 사용해서 오류 페이지 경로를 excludePathPatterns 를 사용해서 빼주면 된다.

package hello.exception.interceptor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.UUID;

@Slf4j
public class LogInterceptor implements HandlerInterceptor {

    public static final String LOG_ID = "logId";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        String requestURI = request.getRequestURI();
        String uuid = UUID.randomUUID().toString();
        request.setAttribute(LOG_ID, uuid);

        log.info("REQUEST [{}][{}][{}][{}]", uuid, request.getDispatcherType(), requestURI, handler);
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        log.info("postHandle [{}]", modelAndView);
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

        String requestURI = request.getRequestURI();
        String logId = (String) request.getAttribute(LOG_ID);
        log.info("RESPONSE [{}][{}][{}]", logId, request.getDispatcherType(), requestURI);
        if (ex != null) {
            log.error("afterCompletion error!!", ex);
        }
    }
}

- hello.exception.interceptor.LogInterceptor

- 로그에 request.getDispatcherType 추가

package hello.exception;
import hello.exception.filter.LogFilter;
import hello.exception.interceptor.LogInterceptor;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;


@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
    }

//    @Bean
    public FilterRegistrationBean logFilter() {
        ...
        return filterRegistrationBean;
    }
}

- hello.exception.WebConfig.java

- excludePathPatterns에 /error-page/** 를 추가해서 에러 페이지 호출 시 인터셉터가 호출되지 않도록 처리.

- 인터셉터와 중복으로 처리되지 않기 위해 앞의 logFilter() 의 @Bean 에 주석처리

* 전체 흐름 정리

- /hello 정상 요청

- /error-ex 오류 요청

> 필터는 DispatchType 으로 중복 호출 제거 ( dispatchType=REQUEST )

> 인터셉터는 경로 정보로 중복 호출 제거( excludePathPatterns("/error-page/**") )

8.7 예외 처리와 오류 페이지 - 스프링 부트 - 오류 페이지1

* 지금까지 예외 처리 페이지를 만들기 위해서 다음과 같은 복잡한 과정을 거쳤다.

> WebServerCustomizer 를 만들고

> 예외 종류에 따라서 ErrorPage 를 추가하고

> 예외 처리용 컨트롤러 ErrorPageController 를 생성

* 스프링 부트는 이러한 과정을 모두 기본으로 제공한다.

- ErrorPage 를 자동으로 등록한다. 이때 /error 라는 경로로 기본 오류 페이지를 설정한다.

> new ErrorPage("/error") , 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.

> 서블릿 밖으로 예외가 발생하거나, response.sendError(...) 가 호출되면 모든 오류는 /error 를 호출하게 된다.

- BasicErrorController 라는 스프링 컨트롤러를 자동으로 등록한다.

> ErrorPage 에서 등록한 /error 를 매핑해서 처리하는 컨트롤러다.

> ErrorMvcAutoConfiguration 클래스가 오류 페이지를 자동으로 등록하는 역할을 한다.

* 스프링 부트가 오류 사용

- 제공하는 기본 오류 메커니즘을 사용하도록 WebServerCustomizer에 있는 @Component 를 주석 처리.

-이제 오류가 발생했을 때 오류 페이지로 /error 를 기본 요청한다.

- 스프링 부트가 자동 등록한 BasicErrorController 는 이 경로를 기본으로 받는다

- BasicErrorController 는 기본적인 로직이 모두 개발되어 있기 때문에 개발자는 오류 페이지 화면만 BasicErrorController 가 제공하는 룰과 우선순위에 따라서 등록하면 된다.

- 정적 HTML이면 정적 리소스, 뷰 템플릿을 사용해서 동적으로 오류 화면을 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다.

* 뷰 선택 우선순위는 BasicErrorController 의 처리 순서이다.

1. 뷰 템플릿 : 타임리프도 오류페이지를 동적으로 수정할 수 있는 페이지
   - resources/templates/error/500.html
   - resources/templates/error/5xx.html
2. 정적 리소스( static , public ) : 수정할 일이 없는 오류들에 대한 정적 리소스 페이지
   - resources/static/error/400.html
   - resources/static/error/404.html
   - resources/static/error/4xx.html
3. 적용 대상이 없을 때 뷰 이름( error )
   - resources/templates/error.html

- 해당 경로 위치에 HTTP 상태 코드 이름의 뷰 파일을 넣어두면 된다.

- 뷰 템플릿이 정적 리소스보다 우선순위가 높고, 404, 500처럼 구체적인 것이 5xx처럼 덜 구체적인 것 보다 우선순위가 높다.

- 5xx, 4xx 라고 하면 500대, 400대 오류를 처리해준다.

- 오류 페이지를 등록 후 실제 호출되는 에러 페이지 확인

> http://localhost:8080/error-404 -> 404.html

> http://localhost:8080/error-400 -> 4xx.html (400 오류 페이지가 없지만 4xx가 있음)

> http://localhost:8080/error-500 -> 500.html

> http://localhost:8080/error-ex -> 500.html (예외는 500으로 처리)

8.8 예외 처리와 오류 페이지 - 스프링 부트 - 오류 페이지2

- BasicErrorController가 제공하는 기본 정보들

* timestamp: Fri Feb 05 00:00:00 KST 2021
* status: 400
* error: Bad Request
* exception: org.springframework.validation.BindException
* trace: 예외 trace
* message: Validation failed for object='data'. Error count: 1
* errors: Errors(BindingResult)
* path: 클라이언트 요청 경로 (`/hello`)

- BasicErrorController 컨트롤러는 위 정보를 model에 담아서 뷰에 전달한다.

- 뷰 템플릿은 이 값을 활용해서 출력할 수 있다

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="utf-8">
</head>
<body>
<div class="container" style="max-width: 600px">
    <div class="py-5 text-center">
        <h2>500 오류 화면 스프링 부트 제공</h2>
    </div>
    <div>
        <p>오류 화면 입니다.</p>
    </div>
    <ul>
        <li>오류 정보</li>
        <ul>
            <li th:text="|timestamp: ${timestamp}|"></li>
            <li th:text="|path: ${path}|"></li>
            <li th:text="|status: ${status}|"></li>
            <li th:text="|message: ${message}|"></li>
            <li th:text="|error: ${error}|"></li>
            <li th:text="|exception: ${exception}|"></li>
            <li th:text="|errors: ${errors}|"></li>
            <li th:text="|trace: ${trace}|"></li>
        </ul>
        </li>
    </ul>

    <hr class="my-4">
</div> <!-- /container -->
</body>
</html>

- templates/error/500.html

* 실행 결과

- 오류 관련 내부 정보들을 고객에게 노출하는 것은 좋지 않다.

- 고객이 해당 정보를 읽어도 혼란만 더해지고, 보안상 문제가 될 수도 있다.

- 그래서 BasicErrorController 오류 컨트롤러에서 오류 정보를 model 에 포함할지 여부 선택할 수 있다

server.error.include-exception=false : exception 포함 여부( true , false )
server.error.include-message=never : message 포함 여부
server.error.include-stacktrace=never : trace 포함 여부
server.error.include-binding-errors=never : errors 포함 여부

- application.properties

- 기본 값이 never 인 부분은 다음 3가지 옵션을 사용할 수 있다.

> never : 사용하지 않음

> always : 항상 사용

> on_param : 파라미터가 있을 때 사용

- on_param 은 파라미터가 있으면 해당 정보를 노출한다.

> 디버그 시 문제를 확인하기 위해 사용할 수 있다.

> 그런데 이 부분도 개발 서버에서 사용할 수 있지만, 운영 서버에서는 권장하지 않는다.

- on_param 으로 설정하고 HTTP 요청시 파라미터를 전달하면 해당 정보들이 model 에 담겨서 뷰 템플릿에서 출력된다.

* 스프링 부트 오류 관련 옵션

- server.error.whitelabel.enabled=true : 오류 처리 화면을 못 찾을 시, 스프링 whitelabel 오류 페이지 적용

- server.error.path=/error : 오류 페이지 경로

> 스프링이 자동 등록하는 서블릿 글로벌 오류 페이지 경로와 BasicErrorController 오류 컨트롤러 경로에 함께 사용된다.

* 확장 포인트

- 에러 공통 처리 컨트롤러의 기능을 변경하고 싶으면 ErrorController 인터페이스를 상속 받아서 구현하거나 BasicErrorController 상속 받아서 기능을 추가하면 된다.

'Spring 정리' 카테고리의 다른 글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 18 (0)	2022.07.19
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 14 (0)	2022.07.10
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 13 (0)	2022.07.10

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15

Spring 정리 2022. 7. 16. 16:44

인프런 강의 53일차.

- 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 1 (김영한 강사님)

- 1편에서 배운 MVC를 활용할 수 있는 기술 습득

- 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

8.1 예외 처리와 오류 페이지 - 프로젝트 생성

- MVC1 편에서 개발한 상품 관리 프로젝트를 약간 다듬어서 form-start 라는 프로젝트로 변환.

- https://start.spring.io

- 프로젝트 선택 Project : Gradle Project

- Language : Java

- Spring Boot : 2.7.0

- Group : hello

- Artifact : exception

- Name : exception

- Package name : hello.exception

- Packaging : Jar

- Java : 11

- Dependencies : Spring Web, Thymeleaf, Lombok, Validation

* gradle.build 실행 후 아래 오류 발생 시 gradle-wrapper.properties에서 gradle 버전을 6.9 이하로 변경해서 다운로드하자. (gradle-6.9-all.zip)

> Unable to find method 'org.gradle.api.artifacts.result.ComponentSelectionReason.getDescription()Ljava/lang/String;'. Possible causes for this unexpected error include: Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.) Re-download dependencies and sync project (requires network)

8.2 예외 처리와 오류 페이지 - 서블릿 예외 처리 - 시작

- 스프링이 아닌 순수 서블릿 컨테이너는 예외를 어떻게 처리하는지 알아보자.

- 서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.

> Exception (예외)

> response.sendError(HTTP 상태 코드, 오류 메시지)

* Exception(예외) 처리 방식

- 자바 직접 실행

> 자바의 메인 메서드를 직접 실행하는 경우 main 이라는 이름의 쓰레드가 실행된다.

> 실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다.

- 웹 애플리케이션

> 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.

> 애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다.

> 그런데 만약에 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까?

> 최종적으로 WAS 까지 예외가 전달된다. WAS는 예외가 올라오면 어떻게 처리 할까?

server.error.whitelabel.enabled=false

- application.properties

- 스프링에서 기본적으로 제공하는 whitelabel 에러 페이지 표시 제외하도록 추가

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Slf4j
@Controller
public class ServletExController {

    @GetMapping("/error-ex")
    public void errorEx() {
        throw new RuntimeException("예외 발생");
    }

}

- hello/exception/servlet/ServletExController.java

- 익셉션 발생시키는 로직 추가

- 실행 시 tomcat이 기본적으로 제공하는 HTTP Status 500 - Internal Server Error가 표시된다.

> 웹 브라우저에서 개발자 모드로 확인해보면 HTTP 상태 코드가 500으로 보인다.

> Exception 의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서 HTTP 상태 코드 500을 반환한다.

* response.sendError(HTTP 상태 코드, 오류 메시지) 처리 방식

- 오류가 발생했을 때 HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해도 된다.

- 이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

- 이 메서드를 사용하면 HTTP 상태 코드와 오류 메시지도 추가할 수 있다.

> response.sendError(HTTP 상태 코드)

> response.sendError(HTTP 상태 코드, 오류 메시지)

@GetMapping("/error-404")
public void error404(HttpServletResponse response) throws IOException {
    response.sendError(404, "404 오류!");
}

@GetMapping("/error-500")
public void error500(HttpServletResponse response) throws IOException {
    response.sendError(500);
}

- hello/exception/servlet/ServletExController.java

- response.sendError로 상태코드 세팅 리턴하는 메소드 추가

- sendError 처리 흐름

> response.sendError() 를 호출하면 response 내부에는 오류가 발생했다는 상태를 저장해둔다.

> 그리고 서블릿 컨테이너는 고객에게 응답 전에 response 에 sendError() 가 호출되었는지 확인한다.

> 그리고 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다

8.3 예외 처리와 오류 페이지 - 서블릿 예외 처리 - 오류 화면 제공

- 서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 고객 친화적이지 않으니 서블릿이 제공하는 기능을 사용해보자.

- 서블릿은 Exception (예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError() 가 호출 되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.

* 에러 페이지 호출 흐름

<web-app>
    <error-page>
        <error-code>404</error-code>
        <location>/error-page/404.html</location>
    </error-page>
    <error-page>
        <error-code>500</error-code>
        <location>/error-page/500.html</location>
    </error-page>
    <error-page>
        <exception-type>java.lang.RuntimeException</exception-type>
        <location>/error-page/500.html</location>
    </error-page>
</web-app>

- 과거에는 web.xml에 각 에러 타입, 코드별 호출 페이지를 지정해서 처리했었다.

- 지금은 스프링 부트를 통해서 서블릿 컨테이너를 실행하기 때문에, 스프링 부트가 제공하는 기능을 사용해서 서블릿 오류 페이지를 등록하면 된다.

* 서블릿 오류 페이지 등록

package hello.exception;

import org.springframework.boot.web.server.ConfigurableWebServerFactory;
import org.springframework.boot.web.server.ErrorPage;
import org.springframework.boot.web.server.WebServerFactoryCustomizer;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        //Springboot에서 제공해주는 ErrorPage 클래스는 사용해 에러 정의
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");

        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);     //에러 페이지 등록
    }
}

- hello/exception/WebServerCustomizer.java

- Servlet 오류를 처리하기 위해 스프링부트가 제공하는 ErrorPage 기능을 사용하였다.

> response.sendError(404) : errorPage404 호출

> response.sendError(500) : errorPage500 호출

> RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

- 오류 페이지는 예외를 다룰 때 해당 예외와 그 자식 타입의 오류를 함께 처리한다.

> RuntimeException 은 물론이고 RuntimeException 의 자식도 함께 처리한다.

* 오류를 처리할 수 있는 컨트롤러 구현

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Slf4j
@Controller
public class ErrorPageController {

    @RequestMapping("/error-page/404")
    public String errorPage404 (HttpServletRequest request, HttpServletResponse response) {
        log.info("errorPage 404");
        return "error-page/404";
    }

    @RequestMapping("/error-page/500")
    public String errorPage500 (HttpServletRequest request, HttpServletResponse response) {
        log.info("errorPage 500");
        return "error-page/500";
    }
}

- hello/exception/servlet/ErrorPageController.java

- 서블릿에서 전달한 페이지를 호출하는 컨트롤러 구현

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="utf-8">
</head>
<body>
<div class="container" style="max-width: 600px">
    <div class="py-5 text-center">
        <h2>404 오류 화면</h2>
    </div>
    <div>
        <p>오류 화면 입니다.</p>
    </div>
    <hr class="my-4">
</div> <!-- /container -->
</body>
</html>

- templates/error-page/404.html

- 오류처리 404 호출 View

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="utf-8">
</head>
<body>
<div class="container" style="max-width: 600px">
    <div class="py-5 text-center">
        <h2>500 오류 화면</h2>
    </div>
    <div>
        <p>오류 화면 입니다.</p>
    </div>
    <hr class="my-4">
</div> <!-- /container -->
</body>
</html>

- templates/error-page/500.html

- 오류처리 500 호출 View

'Spring 정리' 카테고리의 다른 글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 14 (0)	2022.07.10
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 13 (0)	2022.07.10
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 12 (0)	2022.07.05

1 ··· 65 66 67 68 69 70 71 ··· 94

검색결과 리스트

분류 전체보기에 해당되는 글 281건

글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17

인프런 강의 55일차.

'Spring 정리' 카테고리의 다른 글

설정

트랙백

댓글

글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16

인프런 강의 54일차.

'Spring 정리' 카테고리의 다른 글

설정

트랙백

댓글

글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15

인프런 강의 53일차.

'Spring 정리' 카테고리의 다른 글

설정

트랙백

댓글

Mr.Walter

CATEGORY

TAG

RECENT POSTS

RECENT COMMENT

RECENT TRACKBACK

LINK

ARCHIVE

NOTICE

CALENDAR

COUNTER

티스토리툴바