[스프링 DB 1편] #5. 자바 예외 이해 (1)

[newh08]

예외 계층

스프링이 제공하는 예외 추상화를 이해하기 위해선, 자바 기본 예외에 대한 이해가 필요함.
체크예외, 언체크 예외에 대해 다시한번 짚어볼텐데, 그 이유는! 복습 + 실무에 필요한 체크 예외 언체크 예외의 차이와 활용 방안에 대해서 알아보자.
자바 예외의 기본이 탄탄해야 그 위에 쌓아 올릴 수 있는것들이 있음.
스프링에서 왜 이런식으로 예외를 다루지? (서비스 계층에서 SQLException 제거 이유 및 방법) + 실무에서 언제 체크, 언체크 예외를 사용할지?

예외도 객체이기 때문에 최상위 부모는 Object
예외의 최상위는 Throwable
Error : 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다. 예외를 처리하기 보단 그냥 둬야함.
- Throwable 을 Try catch 로 잡으면 안되는데 Error 를 예외로 잡기 때문. 결국 개발자는 Exception 부터 필요한 예외로 생각하고 잡자.
- 참고로 Error 도 언체크 예외이다.
Exception : 체크 예외
- 애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다.
- Exception 과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단 RuntimeException 은 예 외로 한다.
RuntimeException : 언체크 예외, 런타임 예외 (Exception의 모든 자식은 체크 예외이지만, 이 것만 체크 예외임)
- 컴파일러가 체크 하지 않는 언체크 예외이다.
- RuntimeException 과 그 자식 예외는 모두 언체크 예외이다.
- RuntimeException 의 이름을 따라서 RuntimeException 과 그 하위 언체크 예외를 런타임 예외라 고 많이 부른다. 여기서도 앞으로는 런타임 예외로 종종 부르겠다.

예외 기본 규칙

예외는 폭탄돌리기같다. 잡아서 처리하거나, 처리할수 없으면 밖으로 던저야한다.

예외에 대해서는 2가지 기본 규칙을 기억하자.

1. 예외는 잡아서 처리하거나 던져야 한다.
2. 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다.
   • 예를 들어서 Exception 을 catch 로 잡으면 그 하위 예외들도 모두 잡을 수 있다.
   • 예를 들어서 Exception 을 throws 로 던지면 그 하위 예외들도 모두 던질 수 있다.

참고: 예외를 처리하지 못하고 계속 던지면 어떻게 될까?

• 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료된다.
• 웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 때문에 시스템이 종료되면 안된다. WAS가 해당 예외를 받아서 처리하는데, 주로 사용자에게 개발자가 지정한, 오류 페이지를 보여준다.

체크 예외 기본 이해

Exception 과 하위 예외는 모두 컴파일러가 체크하는 체크 예외, 단 RuntimeException 은 예외
체크 예외는 잡아서 처리하거나, 밖으로 던지도록 선언 해야함. 안그럼 컴파일 오류 발생.
컴파일러가 체크하는 체크예외란 도대체 뭐지? 에 대해 코드로 설명.

public class CheckedTest {

    @Test
    void checked_catch() {
        Service service = new Service();
        service.callCatch();
        // 체크 예외를 잡았으므로 테스트 정상 종료
    }

    @Test
    void checked_throw() {
        Service service = new Service();
        Assertions.assertThatThrownBy(service::callThrow)
                .isInstanceOf(MyCheckedException.class);
    }

    /**
     * Exception 을 상속받은 예외는 체크 예외가 된다.
     */
    static class MyCheckedException extends Exception {
        public MyCheckedException(String message) {
            super(message);
        }
    }

    /**
     * Checked 예외는
     * 예외를 잡아서 처리하거나,던지거나 둘중 하나를 필수로 선택해야한다.
     */
    static class Service {
        Repository repository = new Repository();

        /**
         * 예외를 잡아서 처리하는 코드
         */
        public void callCatch() {
            try {
                repository.call();
            } catch (MyCheckedException e) {
                // 예외 처리 로직
            }
        }

        /**
         * 체크 예외를 밖으로 던지는 코드
         * throws 로 꼭 던져야 컴파일 오류가 나지 않음.
         */
        public void callThrow() throws MyCheckedException {
            repository.call();
        }
    }

    static class Repository {
        public void call() throws MyCheckedException { // 체크 예외는 꼭 밖으로 던지도록 선안해야함, 안그러면 컴파일 에러가 뜸.
            throw new MyCheckedException("ex");
        }
    }

}

    /**
     * Exception 을 상속받은 예외는 체크 예외가 된다.
     */
    static class MyCheckedException extends Exception {
        public MyCheckedException(String message) {
            super(message);
        }
    }

RuntimeException 을 상속받으면 언체크 예외.
예외의 기본 기능 중 오류 메시지 보관 기능 사용함. 생성자를 통해 기능 사용.

예외를 잡아서 처리하는 코드

    @Test
    void checked_catch() {
        Service service = new Service();
        service.callCatch();
        // 체크 예외를 잡았으므로 테스트 정상 종료
    }

test -> service.callCatch() -> repository.call()-> 예외 발생!
-> service.callCatch() 예외 처리함. -> test 정상 종료

예외 잡는 코드

        public void callCatch() {
            try {
                repository.call();
            } catch (MyCheckedException e) {
                // 예외 처리 로직
            }
        }

catch 에 Exception 을 적어도 잡아줌.

실행 결과

[Test worker] INFO hello.jdbc.exception.basic.CheckedTest - 예외 처리, message=ex hello.jdbc.exception.basic.CheckedTest$MyCheckedException: ex  at
 hello.jdbc.exception.basic.CheckedTest$Repository.call(CheckedTest.java:64)  at
 hello.jdbc.exception.basic.CheckedTest$Service.callCatch(CheckedTest.java:45)
 at hello.jdbc.exception.basic.CheckedTest.checked_catch(CheckedTest.java:14)

• 실행 결과 로그를 보면 첫줄은 우리가 남긴 로그가 그대로 남는 것을 확인할 수 있다.
• 그런데 두 번째 줄 부터 예외에 대한 스택 트레이스가 추가로 출력된다.
• 이 부분은 로그를 남길 때 로그의 마지막 인수에 예외 객체를 전달해주면 로그가 해당 예외의 스택 트레이스를 추 가로 출력해주는 것이다.
  • log.info("예외 처리, message={}", e.getMessage(), e); 여기서마지막에있는 e 부 분이다.

예외를 밖으로 던지는 경우

    @Test
    void checked_throw() {
        Service service = new Service();
        Assertions.assertThatThrownBy(service::callThrow)
                .isInstanceOf(MyCheckedException.class);
    }

servuce.callThrow() 에서 예외를 던졌기 때문에 테스트 메서드까지 예외가 올라온다.
test -> service.callCatch() -> repository.call()-> 예외 발생!
-> service.callCatch() 예외 던짐. -> test 예외 도착

예외를 밖으로 던지는 코드

        public void callThrow() throws MyCheckedException {
            repository.call();
        }

• 위 코드에서 만약 throws 를 지정하지 않으면 컴파일 오류 발생.
  • Unhandled exception: hello.jdbc.exception.basic.CheckedTest.MyCheckedException
• 체크 예외의 경우 예외를 잡아서 처리하거나 또는 throws 를 지정해서 예외를 밖으로 던진다는 선언을 필수로 해주어야 한다.

던질때도 잡을때와 마찬가지로 Exception 을 던질 수 있음.

체크 예외의 장단점
체크 예외는 예외를 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외 를 필수로 선언해야 한다. 그렇지 않으면 컴파일 오류가 발생한다. 이것 때문에 장점과 단점이 동시에 존재한다.

• 장점: 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 훌륭한 안전 장치이다.
• 단점: 하지만 실제로는 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야 하기 때문에, 너무 번거로운 일이 된다. 크게 신경쓰고 싶지 않은 예외까지 모두 챙겨야 한다. 추가로 의존관계에 따른 단점도 있는데 이 부분 뒤에서 설명.
  나는 신경쓰고싶지 않은 에러 (서비스에서 다룰 수 없는 에러)를 전부 throws 애 적어줘야함.

[YuDeokRin]

이건 예전에 제가 정리했던 내용인데 다른분들 참고 하셔도될듯합니다 ㅎㅎ
https://yudeokrin.github.io/posts/2022-11-09-page69

[seyxxn]

제일 빨리 하셨네요 ㅎㅎ 수고하셨습니당~~