스프링 DB 1(김영한 강의) - 섹션 5 : 자바 예외 이해

섹션 목적 : 자바의 예외에 대해 이해해보자

 

1. 예외 계층

   (1) Object - Throwable - Error, Exception

   (2) Error : 메모리 부족, 시스템 오류와 같이 복구 불가능한 예외. 개발자는 잡으려하면 안됨

   (3) Exception - ..., RuntimeException

   (4) Exception과 그 하위 예외(RuntimeException 제외) -> 체크 예외

   (5) RuntimeException과 그 하위 예외 -> 언체크 예외

 

2. 예외 기본 규칙

   (1) 규칙

      ① 예외는 잡아서 처리하거나, 밖으로 던져야한다(자기를 호출한 상위 메소드로)

      ② 예외를 잡거나 던질 때, 그 예외의 자식들도 함께 처리된다

   (2) 예외를 처리하지 못하고 계속 던지면?

      ① 자바 main()의 경우, 예외 로그를 출력하고 종료

      ② 웹 애플리케이션의 경우 시스템이 종료되면 안됨. 따라서 WAS가 예외를 받아서 처리함. 사용자에게 개발자가 지정한 예외 페이지를 보여줌

 

3. 체크 예외 기본 이해

   (1) Exception과 그 하위 예외(RuntimeException 제외)는 컴파일러가 체크하는 체크 예외

   (2) 체크 예외는 처리하거나 밖으로 던지도록 선언해야함. '체크 예외를 어떻게 하겠다'라는 것을 명시적으로 보여줘야함. 그렇지 않으면 컴파일 오류 발생

   (3) 장점 : 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 안전장치

   (4) 단점 : 개발자가 신경쓰고 싶지 않은 체크 예외를 잡거나 던져야하기 때문에 너무 번거로움. 또한 의존관계에 따른 단점도 존재함

 

4. 언체크 예외 기본 이해

   (1) RuntimeException과 그 하위 예외는 컴파일러가 체크하지 않는 언체크 예외

   (2) 언체크 예외는 꼭 잡아서 처리하거나 던지는 것을 명시적으로 표현할 필요가 없음. 처리하지 않으면 자동적으로 던짐

   (3) 언체크 예외는 throws를 선언해도 됨. 중요한 예외의 경우에 이렇게 선언해두면, 해당코드를 호출하는 개발자가 IDE를 통해 볼 수 있음

   (4) 장점 : 신경쓰고 싶지 않은 예외를 무시할 수 있음. 신경쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 됨

   (5) 단점 : 개발자가 실수로 예외를 누락할 수 있음

   (6) 따라서, 체크 예외와 언체크 예외의 차이는 예외를 처리하지 않을 때 밖으로 던지는 부분에 있음. 체크는 명시적으로 throws를 해줘야하는 반면, 언체크는 생략해도 됨

 

5. 체크 예외 활용

   (1) 그렇다면 언제 체크 or 언체크를 사용해야할까?

   (2) 원칙

      ① 기본적으로 언체크를 활용하자

      ② 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에 사용하자. 개발자가 실수로 이 예외를 놓칠 수 없게끔 만들 때 사용

   (3) 체크 예외 문제점

      ① Repository에서 발생한 Exception이 해결할 수 없는 Service와 Controller까지 올라오면서 신경쓰고 싶지 않은 예외를 처리해야함

      ② 컨트롤러나 서비스는 throws Exception을 통해 예외에 의존하게 됨. 만약 Repository가 JDBC에서 JPA로 변경돼서 JPA Exception이 발생할 경우, 서비스와 컨트롤러 모두 코드를 변경해야하는 문제가 발생함

   (4) 그렇다고 체크 예외를 공통으로 처리하기 위해 throws Exception을 사용하지 말자

 

6. 언체크 예외 활용

   (1) SQLException을 RuntimeSQLExcption으로 변경. Service와 Controller는 해당 예외에 의존할 필요가 없음

   (2) 서비스나 컨트롤러는 이런 복구 불가능한 예외를 신경쓸 필요가 없음

   (3) 또한, 서비스나 컨트롤러는 해당 예외에 의존할 필요가 없음

   (4) 이렇게 런타임 예외로 바꾸게 되면

      ① 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 컨트롤러나 서비스는 코드를 변경할 필요가 없음

      ② 해당 기술에 의존하는 Repository와 ControllerAdvice만 변경하면 됨

 

7. 예외 포함과 스택 트레이스

   (1) 예외를 전활할 때는 기존 예외를 생성자 안에 감싸서 전환해야 함

   (2) 그래야 기존에 발생한 예외으 스택 트레이스를 확인할 수 있음


이펙티브 자바 - 아이템 6 : 불필요한 객체 생성을 피하라

- 똑같은 기능의 객체를 매번 생성하는 것보다 객체 하나를 재사용하는 것이 좋다

- 예를 들어서, String s = new String("bikini")를 반복문에서 사용할 경우, 계속해서 새로운 인스턴스가 만들어지게 된다

- 따라서, String s = "bikini"를 사용함으로써 같은 문자열 객체가 재사용되게 해야한다

- 정적 팩토리 메소드를 사용하면 불필요한 객체 생성을 막을 수 있다(ex. Boolean.valueOf(String) -> 항상 같은 Boolean 객체가 반환된다)

- 생성비용이 비싼 경우 미리 클래스 초기화 과정에서 생성해두고 이 인스턴스를 재사용하는 방법으로 사용한다

- 박싱된 기본 타입보다는 기본타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의해야 한다

- 예를 들어 Long sum = 0L에서 sum에 계속 숫자를 더하면, Long은 불필요한 객체가 무수히 만들어지는 경우가 발생한다


코테준비

1. 프로그래머스 - k번째 수

- stream을 이용해서 배열을 subarray할 수 있다는 것을 깨달았음


오늘 하루도 고생했고, 다음주 토요일에 토스 코테 한번 봐보자!!!

'TIL(Today I Learned)' 카테고리의 다른 글

2023.07.03  (0) 2023.07.03
2023.06.30  (0) 2023.06.30
2023.06.28  (0) 2023.06.29
2023.06.27  (0) 2023.06.27
2023.06.26  (0) 2023.06.26

+ Recent posts