스프링에서 예외 처리 하는 법

https://mangkyu.tistory.com/204

BasicErrorController를 통한 기본적인 에러 발생 흐름

• WAS의 에러 발생시 흐름은 아래와 같다
  • 컨트롤러 하위에서 에러 발생하고 별도 에러 처리하지 않으면 WAS까지 에러 전달하고 다시 에러 컨트롤러로 에러 처리를 위해 전달한다
• 서블릿이 dispatcher 타입으로 구분하는데 일반적인 요청은 REQUEST, 에러 처리 요청은 ERROR다
• 요청이 2번 생기는 것은 아니나 1번의 요청이 2번 전달되는 것이다

WAS(톰캣) -> 필터 -> 서블릿(디스패처 서블릿) -> 인터셉터 -> 컨트롤러
-> 컨트롤러(예외발생) -> 인터셉터 -> 서블릿(디스패처 서블릿) -> 필터 -> WAS(톰캣)
-> WAS(톰캣) -> 필터 -> 서블릿(디스패처 서블릿) -> 인터셉터 -> 컨트롤러(BasicErrorController)

BasicErrorController 에러 속성

• 기본적으로 생성되는 DefaultErrorAttribute에는 여러 정보를 담고 있다

  • timestamp : 발생 시간
  • status : HTTP 상태코드
  • error : 에러코드
  • path : 에러 발생 uri
  • exception : 최상위 예외클래스 이름
  • message → 에러내용, 2.3부터 클라이언트에 너무 많은 정보 노출 방지를 위해 default로 제공 X
  • errors → BindingException에 의해 생긴 에러 목록
  • trace → 스택 트레이스로 운영환경에서는 노출하지 않는 것이 좋다

• 기본적으로 생성되는 DefaultErrorAttribute에는 여러 정보를 담고 있는데 여기서 에러 코드는 500으로 설정된다.

  • 이는 에러가 처리되지 않고 WAS가 에러를 전달받았기 때문

{
    "timestamp": "2021-12-31T03:35:44.675+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "trace": "java.util.NoSuchElementException: No value present ...",
    "message": "No value present",
    "path": "/product/5000"
}

• 만약 실제 에러 발생 이유가 해당 데이터가 존재하지 않아서라면, “Item with id 1 not found”와 함께 404 status 코드를 에러 응답으로 받는 것이 좋을 것이다.

server.error.include-message: always
server.error.include-binding-errors: always
server.error.include-stacktrace: always // 운영 환경에서는 X
server.error.include-exception: false

예외 처리 방법

HandlerExceptionResolver