45.01_[Spring MVC] 예외 처리_(2) Business Logic Exception_22.10.26

Service Layer Exception Handling

>애플리케이션에서 발생하는 예외 구분
-Checked Exception
: 발생한 예외를 catch하여 체크한 후 체크한 예외를 복구 및 회피와 같은 구체적인 처리를 해야 하는 예외를 의미함.
: 예시로, ClassNotFoundException 등이 있다.
-Unchecked Exception
: 발생한 예외를 catch하되, 예외에 대한 처리를 따로 할 필요가 없는 예외를 의미함.
: 예시로, NullPointerException, ArrayIndexOutOfBoundsException 등이 있음.
: 보통 Unchecked Exception은 코드 작성에서 실수가 있어 발생하는 경우이고, 이런 경우의 예외들은 보통 RuntimeException을 상속한다.
: Java, Spring 이 많은 RuntimeException을 지원하지만, 이따금 개발자가 직접 RuntimeException을 이용해서 예외를 만들어야 하는 경우도 있다.

>개발자가 의도적으로 Exception을 throw하는 상황
-백엔드 서버와 외부 시스템과의 연동에서 발생하는 에러 처리 상황
: 외부 시스템에서 예외가 발생하여 프로세스가 중단되면, 이를 처리하는 것은 무의미하다. 이땐 백엔드 서버에서 예외를 의도적으로 던져서 클라이언트에게 에러 정보를 알려주는 것이 좋다.
-시스템 내부에서 조회하려는 리소스가 없는 경우
: 클라이언트에서 요청한 데이터가 데이터베이스에 존재하지 않는 경우, 서비스 계층에서 예외를 던져 클라이언트에게 리소스가 없다는 것을 알릴 수 있다.

>서비스 계층에서 예외 던지기
: 비즈니스 로직의 상황에 맞게 개발자가 의도적으로 예외를 던지는 상황이 종종 있다.
: 서비스 계층에서 Exception을 throw하면 메서드를 호출한 지점으로 던지게 된다. 즉, API 계층의 Controller의 Handler method 쪽에서 던진 예외를 잡을 수 있다.
: 또한, 이미 Exception Advice을 만들어 공통화를 해두었다면, 서비스 계층에서 던진 예외 역시 Exception Advice에서 처리하면 된다.

>Catch exception by Service Layer in Exception Advice
@ExceptionHandler
@ResponseStatus(HttpStatus.NOT_FOUND)
매개변수 : RuntimeException
고칠점=>서비스 계층에서 예외를 던지는 상황은 다양할 수 있다. 따라서 매개변수의 참조형을 RuntimeException이 아닌 더 구체적인 참조형으로 잡는 것이 좋다. (명확한 의도 표출)
또한, 추가적으로 메서드명에서도 의도를 암시하는 이름을 사용하자.

>Custom Exception
: 서비스 계층에서 예외를 던질 때 더 명확한 상황을 표현하기 위해 사용자 정의 예외를 만들 수 있다.

>Custom Exception 생성
-enum 사용
: enum으로 정의하면 다양한 유형의 예외를 추가할 수 있다. (enum을 다시 살펴보자)
-custom Exception class 생성
: enum의 정보를 멤버 변수로 갖고, RuntimeException을 상속받는 클래스를 활용한다.
: 생성자로 enum의 객체(?)를 받는다.
-서비스 계층에 적용
: 비즈니스 로직(메서드) 중 예상되는 예외를 던지는 부분에서 custom exception class의 객체를 생성한다. 생성자는 enum의 코드(멤버 변수)를 던진다
-Exception Advice 적용
: 메서드명, 매개변수 참조형을 확실히한다.
: @ResponseStatus(HttpStatus.NOT_FOUND) 보다는 ResponseEntity를 사용하여 상황에 맞게(동적으로) HttpStatus를 출력하게 만든다.
-ErrorResponse 적용
: 실제로 에러 정보를 맞아 추출하고 가공하는 클래스인 ErrorResponse에 해당 예외를 어떻게 추출하고 어떻게 가공하여 반환할지에 대한 로직을 작성한다.

>@ResponseStatus 와 ResponseEntity
: 고정된 HttpStatus를 출력할 경우에는 @ResponseStatus을 붙이는 것이 편하고, 다양한 유형에 따라 동적으로 HttpStatus를 출력할 경우는 ResponseEntity을 사용하는 것이 유용하다.