Skip to content

Latest commit

 

History

History
77 lines (51 loc) · 3.53 KB

230425_section5.md

File metadata and controls

77 lines (51 loc) · 3.53 KB
Raw

Section 5) 자바 예외 이해

예외 계층

image

  • Error : 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다.(언체크 예외) 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다.

  • Exception : 체크 예외, Exception 부터 필요한 예외로 생각하고 잡으면 된다.

    • Exception 과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다 단 RuntimeException 은 예외로 한다.

  • RuntimeException : 언체크 예외, 런타임 예외

    • 컴파일러가 체크 하지 않는 언체크 예외이다. 그 자식 예외는 모두 언체크 예외이다.

예외 기본 규칙

image

  • 예외가 발생하면 예외를 상위로 던지거나 예외를 처리한다.

언체크 예외 기본 이해체크

예외 VS 언체크 예외

  • 체크 예외: 예외를 잡아서 처리하지 않으면 항상 throws 에 던지는 예외를 선언해야 한다.
  • 언체크 예외: 예외를 잡아서 처리하지 않아도 throws 를 생략할 수 있다.

체크 예외 활용

기본적으로 언체크(런타임) 예외를 사용하자. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자.

  • 계좌 이체 실패 예외
  • 결제시 포인트 부족 예외
  • 로그인 ID, PW 불일치 예외

체크 예외 문제점

image

  • method() throws SQLException, ConnectException application logic에서 처리할 방법 없으니까 계속 예외 던짐
    • 복구 불가능한 예외에 의해서
  • 웹 애플리케이션이라면 서블릿의 오류 페이지나, 또는 스프링 MVC가 제공하는 ControllerAdvice 에서 이런 예외를 공통으로 처리한다.
  • API라면 보통 HTTP 상태코드 500(내부 서버 오류)을 사용해서 응답을 내려준다.
  • 이렇게 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 개발자가 오류를 빨리 인지할 수

image logic() throws SQLException logic() throws JPAException 다 바꿔야 함 체크 예외는 예외를 강제로 의존해야해서 다 들고다님

public void request() throws SQLException, ConnectException {

throws Exception? 하위 예외 다 하고, 무슨 예외 던지는지 알 수가 없음 => 런타임 예외

예외 전환 리포지토리에서 체크 예외인 SQLException 이 발생하면 런타임 예외인 RuntimeSQLException 으로 전환해서 예외를 던진다.

image

예외 포함과 스택 트레이스

예외를 전환할 때는 꼭! 기존 예외를 포함해야 한다. 그렇지 않으면 스택 트레이스를 확인할 때 심각한 문제가 발생한다. 로그를 출력할 때 마지막 파라미터에 예외를 넣어주면 로그에 스택 트레이스를 출력할 수 있다. 예) log.info("message={}", "message", e)

throw new RuntimeSQLException(e); //기존 예외(e) 포함

예외 전환 할 때 기존 예외인 e를 넣어줘야 로그로 무슨 예외가 터졌는지 확인할 수 있다.