5-6. 언체크 예외 활용

 

- SQLException을 런타임예외인 RuntimeSQLException으로 변환했다.

- ConnectException 대신에 RuntimeConnectException을 사용하도록 바꾸었다.

 

 

 

 

# UncheckedAppTest

 

생성자 중 Throwable을 파라미터로 갖는 생성자는 파라미터의 예외를 가질 수 있다.

-> 스택 트레이스 출력 시 두 예외 모두 출력된다.

 

 

 

 

 

 

- 모두 런타임 예외로 변환하여 던졌다.

 

 

 

1. 대부분 복구 불가능한 예외

  - 어차피 못 고치므로 런타임예외로 사용하여 서비스나 컨트롤러가 신경쓰지 않아도 되게 한다.

 

2. 의존관계에 대한 문제

  - 런타임 예외는 무시해도된다.

  -> 구현 기술이 변경되도 예외에 의존하지 않아 바꿀게 없다.

 

 

 

 

 

 

 

# 정리

 

 

처음 자바를 설계할 당시에는 체크예외가 더 나은 선택이라 생각했다. 그래서 자바가 기본으로 제공하는 기능들에는 체크예외가 많다. 그런데 시간이 흐르면서 복구할 수 없는 예외가 너무 많아졌다. 특히 라이브러리를 점점 더 많이 사용하면서 처리해야 하는 예외도 더 늘어났다. 체크예외는 해당 라이브러리들이 제공하는 모든 예외를 처리할 수 없을때 마다 throws에 예외를 덕지덕지 붙어야 했다. 그래서 개발자들은 throws Exception 하는 방법도 자주 사용하게 되었다. 물론 이 방법은 사용 하면 안된다. 모든 예외를 던진다고 선언하는 것인데, 결과적으로 어떤 예외를 잡고 어떤 예외를 던지는지 알 수 없기때문이다. 체크예외를 사용한다면 잡을 건 잡고 던질예외는 명확하게 던지도록 선언해야한다.

 

체크예외의 이런 문제점 때문에 최근 라이브러리들은 대부분 런타임예외를 기본으로 제공한다. JPA 기술도 런타임 예외를 사용한다. 스프링도 대부분 런타임예외를 제공한다. 런타임예외도 필요하면 잡을수있기 때문에 필요한 경우에는 잡아서 처리하고, 그렇지 않으면 자연스럽게 던지도록둔다. 그리고 예외를 공통으로 처리하는 부분을 앞에 만들어서 처리하면 된다.

 

 

ex) JPA의 EntityManger

docs 에 발생할 수 있는 런타임예외를 적어두었다.

 

 

 

 

꾸준히 다시보자.

 

1. 221014

2. 221101