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

[YONGHYNG]

-Object: 예외도 객체(객체의 최상위 부모)이다.
-Throwable: 최상위 예외이다.
-Error: 메모리 부족, 심각한 오류, 복구 불가능한 시스템 예외, 개발자는 이 예외 잡으려함 안 된다.

• 상위 예외를 catch로 잡으면 하위 예외까지 잡음, 따라서 어플 로직에서 Throwable 예외도 잡으면 안 됨, Error 예외가 잡힐 수 있기 때문이다.
• Error도 언체크 예외이다.
  **언체크 예외: 자바 프로그램이 실행될 때 생길 수 있는 오류(컴파일 할 때는 문제 없음)

-Exception: 체크 예외

• 애플리케이션 로직에서 사용하는 최상위 예외이다.
• Exception과 하위 예외는 모두 컴파일러 체크하는 체크 예외이고 RuntimeException은 예외이다.

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

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

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

**예외를 처리 못하고 계속 던진다면?

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

체크 예외 기본 이해
**자바에서 컴파일할 때 컴파일러가 꼭 예외 처리를 확인하는 예외 반드시 예외 처리 코드(try-catch)를 추가하거나 throws 키워드로 예외를 던져야함

• Exception과 하위 예외는 모두 컴파일러가 체크하는 체크 예외, 단 RuntimeException은 예외로 한다.
• 체크 예외는 잡아서 처리하거나, 밖으로 던지도록 선언해야한다. 그렇지 않으면 컴파일 오류가 난다.

체크 예외 전체 코드

package hello.jdbc.exception.basic;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

@Slf4j
public class CheckedTest {

 @Test
 void checked_catch() {
 Service service = new Service();
 service.callCatch();
 }
 @Test
 void checked_throw() {
 Service service = new Service();
 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();
 /**
 * MyCheckedException 예외를 잡아서 처리한다.
 * catch는 해당 타입과 그 하위 타입 모두를 잡는다. 예외를 지정하면 해당 예외와 그 하위 타입 예외를 모두 잡는다.
 * 정확하게 MyCheckedException만 잡고 싶다면 catch에 MyCheckedException 적으면 된다.
 */
 } catch (MyCheckedException e) { 
 log.info("예외 처리, message={}", e.getMessage(), e);
 }
 }

 /**
 * 체크 예외를 밖으로 던지는 코드
 * 체크 예외는 예외를 잡지 않고 밖으로 던지려면 throws 예외를 메서드에 필수로 선언
 * 체크 예외를 처리할 수 없을 때는 method() throws 예외를 사용, 밖으로 던질 예외를 필수로 지정해야 함, MyCheckedException을 밖으로 던지도록 지정함
 * 언체크 예외는 주로 생략하지만, 중요한 예외의 경우 이렇게 선언해두면 해당 코드를 호출하는 개발자가 이런 예외가 발생한다는 점을 IDE를 통해 편리하게 인지 가능하다.
 */
 public void callThrow() throws MyCheckedException {
 repository.call();
 }
 }
 static class Repository {
 public void call() throws MyCheckedException {
 throw new MyCheckedException("ex");
 }
 }
}

• Exception을 상속받으면 체크 예외가 된다.
• RuntimeException을 상속 받음 언체크 예외가 된다. 자바 문법이다.
• 예외 기능중, 오류 메시지 보관 기능도 있다.

• 첫 줄 우리가 남긴 로그가 남았다.
• 두 번째 줄 예외에 대한 스택 트레이스가 추가 됐다.
• 로그를 남길 때 로그의 마지막 인수에 예외 객체를 전달해주면 로그가 해당 예외의 스택 트레이스를 추가로 출력해주는 것이다.
  ** 스택 트레이스: 오류 발생 위치, 경로 정보

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

• throws에 MyCheckedException 의 상위 타입인 Exception을 적어주어도 MyCheckedException을 던질 수 있다.
• throws에 지정한 타입과 그 하위 타입 예외를 밖으로 던진다.

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

• 장점: 개발자 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 안전 장치
• 단점: 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야 함, 크게 신경쓰고 싶지 않은 예외까지 모두 챙겨야 한다.

언체크 예외 기본 이해

-RuntimeException과 그 하위 예외는 언체크 예외로 분류된다.
-컴파일러가 예외를 체크하지 않는다는 뜻이다.
-언체크 예외는 체크 예외와 기본적으로 동일하다. 차이는 예외를 던지는 throws 선언하지 않고, 생략 가능, 이 경우 자동으로 던진다.

언체크 예외 전체 코드

package hello.jdbc.exception.basic;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

@Slf4j
public class UncheckedTest {

 @Test
 void unchecked_catch() {
 Service service = new Service();
 service.callCatch();
 }

 @Test
 void unchecked_throw() {
 Service service = new Service();
 assertThatThrownBy(() -> service.callThrow())
 .isInstanceOf(MyUncheckedException.class);
 }

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

 /**
 * UnChecked 예외는
 * 예외를 잡거나, 던지지 않아도 된다.
 * 예외를 잡지 않으면 자동으로 밖으로 던진다.
 */
 static class Service {
 Repository repository = new Repository();

 /**
 * 필요한 경우 예외를 잡아서 처리하면 된다.
 */
 public void callCatch() {
 try {
 repository.call();
 } catch (MyUncheckedException e) {
 //예외 처리 로직
 log.info("예외 처리, message={}", e.getMessage(), e);
 }
 }

 /**
 * 예외를 잡지 않아도 된다. 자연스럽게 상위로 넘어간다.
 * 체크 예외와 다르게 throws 예외 선언을 하지 않아도 된다.
 * 컴파일러가 체크하지 않기 때문에 언체크 예외이다.
 */
 public void callThrow() {
 repository.call();
 }
 }

 static class Repository {
 public void call() {
 throw new MyUncheckedException("ex");
 }
 }
}

언체크 예외의 장단점
-언체크 예외는 예외를 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외를 생략할 수 있다.

• 장점: 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다. 신경 쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 되는 장점이 있다.
• 단점: 언체크 예외는 개발자가 실수로 예외를 누락할 수 있다. 체크 예외는 컴파일러를 통해 예외 누락을 잡아준다.

체크 예외 활용

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

• 체크예외 사용 ex) 계좌 이체 실패, 결제시 포인트 부족, 로그인 id, pw 불일치

체크 예외의 문제점

-체크 예외는 컴파일러가 예외 누락을 체크해주기 때문에 개발자가 실수로 예외를 놓치는 것을 막아준다. 그래서 항상 명시적으로 예외를 잡아서 처리하거나, 처리할 수 없을 때는 예외를 던진다. method() throws 예외로 선언해야 한다.

-리포지토리는 db에 접근, 데이터를 저장하고 관리한다. 여기서는 SQLExecption 체크 예외 던진다.
-NetworkClient는 외부 네트워크에 접속, 어떤 기능을 처리하는 객체이다. 여기서는 ConnectException 체크 예외를 던진다.
-서비스는 리포지토리와 NetworkClient 둘 다 호출한다.

• 따라서 두 곳에서 올라오는 체크 예외인 SQLException 과 ConnectException 을 처리해야 한다.

• 그런데 서비스는 이 둘을 처리할 방법을 모른다. ConnectException 처럼 연결이 실패하거나,
  SQLException 처럼 데이터베이스에서 발생하는 문제처럼 심각한 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다.

• 서비스는 SQLException과 ConnectException을 처리할 수 없으므로 둘 다 밖으로 던진다.

• 체크 예외이기 때문에 던질 경우 method() throws SQLException, ConnectException

-웹 어플리케이션이라면 서블릿의 오류 페이지나, 스피링 mvc가 제공하는 ControllerAdvice 에서 이런 예외를 공통으로 처리한다.

• 위 문제는 사용자에게 어떤 문제가 발생했는지 설명이 어렵다.(보안 및 용어 이해의 어려움)
• API라면 보통 HTTP 상태코드 500(내부 서버 오류)를 사용해서 응답을 내려준다.
• 이렇게 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 개발자가 오류를 빨리 인지할 수 있도록 메일, 알림(문자, 슬랙)등을 통해서 전달 받아야 한다.

체크 예외 문제점 - 코드 - CheckedAppTest

package hello.jdbc.exception.basic;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import java.net.ConnectException;
import java.sql.SQLException;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
@Slf4j
public class CheckedAppTest {
 @Test
 void checked() {
 Controller controller = new Controller();
 assertThatThrownBy(() -> controller.request())
 .isInstanceOf(Exception.class);
 }

 /**
 * 체크 예외를 처리하지 못해서 밖으로 던지기 위해 request() throws SQLException, ConnectException을 선언
 */
 static class Controller {
 Service service = new Service();
 public void request() throws SQLException, ConnectException {
 service.logic();
 }
 }

 /**
 * 체크 예외를 처리하지 못해서 밖으로 던지기 위해 logic() throws SQLException, ConnectException을 선언 
  */
 static class Service {
 Repository repository = new Repository();
 NetworkClient networkClient = new NetworkClient();
 public void logic() throws SQLException, ConnectException {
 repository.call();
 networkClient.call();
 }
 }
 static class NetworkClient {
 public void call() throws ConnectException {
 throw new ConnectException("연결 실패");
 }
 }
 static class Repository {
 public void call() throws SQLException {
 throw new SQLException("ex");
 }
 }
}

2가지 문제

1. 복구 불가능한 예외

• 대부분의 예외는 복구가 불가능하다. 가능한 예도 있지만 아주 적다.
• 문제: SQLException 을 예를 들면 데이터베이스에 무언가 문제가 있어서 발생하는 예외이다. SQL 문법에 문제가 있을 수도 있고, 데이터베이스 자체에 뭔가 문제가 발생했을 수도 있다. 데이터베이스 서버가 중간에 다운 되었을 수도 있다. 이런 문제들은 대부분 복구가 불가능하다. 특히나 대부분의 서비스나 컨트롤러는 이런 문제를 해결할 수는 없다. 따라서 이런 문제들은 일관성 있게 공통으로 처리해야 한다. 오류 로그를 남기고 개발자가 해당 오류를 빠르게 인지하는 것이 필요하다.
• 해결책: 서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.

2. 의존 관계에 대한 문제

• 체크 예외의 또 다른 심각한 문제는 예외에 대한 의존 관계 문제이다.
• 예외는 복구 불가능한 예외이다. 그런데 체크 예외이기 때문에 컨트롤러나 서비스 입장에서는 본인이 처리할 수 없어도 어쩔 수 없이 throws를 통해 던지는 예외를 선언해야 한다.

• throws SQLException, ConnectException 처럼 예외를 던지는 부분을 코드에 선언하는 것이 문제가 되는 이유: 컨트롤러에서 java.sql.SQLException을 의존하기 때문이다.
• JDBC 기술이 아닌 다른 기술로 변경된다면 ex) SQLException -> JPAException 으로 변경된다면
  SQLException에 의존하던 모든 서비스, 컨트롤러의 코드를 JPAException에 의존하도록 고쳐야 한다.

서비스나 컨트롤러 입장에서는 처리할 수 없는 예외를 의존해야 하는 큰 단점이 발생하게 된다. 결과적으로 OCP, DI 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 체크 예외 때문에 발목이 잡힌다.

-JDBC -> JPA 같은 기술로 변경하면 예외도 함께 변경해야한다. 예외를 던지는 모든 부분도 변경해야 한다.

• logic() throws SQLException -> logic() throws JAPException (JPA 예외는 이러지 않음 예임)

throws Exception
-SQLException, ConnectException 같은 시스템 예외는 컨트롤러나 서비스에는 대부분 복구가 불가능하고 처리할 수 없는 체크 예외이다. 따라서 다음과 같이 처리해주어야 한다.
-void method() throws SQLException, ConnectException {..}
-Excetion 도 가능 void method() throws Exception {..}
Exception은 편하지만 문제 발생: 다른 체크 예외 체크할 수 있는 기능 무효화, 중간에 중요한 체크 예외가 발생해도 컴파일러는 Exception을 던지기 때문에 문법에 맞다고 판단, 컴파일 오류가 발생하지 않는다.

언체크 예외 활용

런타임 예외 사용

• SQLException을 런타임 예외인 RuntimeSQLException 으로 변환했다.
• ConnectException 대신에 RuntimeConnectException 을 사용하도록 바꾸었다.
• 런타임 예외이기 때문에 서비스, 컨트롤러는 해당 예외들을 처리할 수 없다면 별도의 선언 없이 그냥 두면 된다.

런타임 예외 사용 변환 - 코드 - UncheckedAppTest

package hello.jdbc.exception.basic;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import java.sql.SQLException;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
@Slf4j
public class UncheckedAppTest {
 @Test
 void unchecked() {
 Controller controller = new Controller();
 assertThatThrownBy(() -> controller.request())
 .isInstanceOf(Exception.class);
 }
 @Test
 void printEx() {
 Controller controller = new Controller();
 try {
 controller.request();
 } catch (Exception e) {
 //e.printStackTrace();
 log.info("ex", e);
 }
 }
 static class Controller {
 Service service = new Service();
 public void request() {
 service.logic();
 }
 }
 static class Service {
 Repository repository = new Repository();
 NetworkClient networkClient = new NetworkClient();
 public void logic() {
 repository.call();
 networkClient.call();
 }
 }
 static class NetworkClient {
 public void call() {
 throw new RuntimeConnectException("연결 실패");
 }
 }
 static class Repository {
 public void call() {
 try {
 runSQL();
 } catch (SQLException e) {
 throw new RuntimeSQLException(e);
 }
 }
 private void runSQL() throws SQLException {
 throw new SQLException("ex");
 }
 }

 /**
 * 예외 전환
 * 
 */
 static class RuntimeConnectException extends RuntimeException {
 public RuntimeConnectException(String message) {
 super(message);
 }
 }
 static class RuntimeSQLException extends RuntimeException {
 public RuntimeSQLException() {
 }
 public RuntimeSQLException(Throwable cause) {
 super(cause);
 }
 }
}

런타임 예외 throws 생략

class Controller {
 public void request() {
 service.logic();
 }
}
class Service {
 public void logic() {
 repository.call();
 networkClient.call();
 }
}

-런타임 예외이기 떄문에 컨트롤러나 서비스 예외를 처리할 수 없다면 다음 부분 생략 가능

런타임 예외 throws 생략

class Controller {
 public void request() {
 service.logic();
 }
}
class Service {
 public void logic() {
 repository.call();
 networkClient.call();
 }
}

• method() throws RuntimeSQLException, RuntimeConnectException
• 따라서 컨트롤러와 서비스에서 해당 예외에 대한 의존 관계가 발생하지 않는다.

• 런타임 예외를 사용하면 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 컨트롤러, 서비스에서는 코드를 변경하지 않아도 된다.
• 구현 기술이 변경되는 경우, 예외를 공통으로 처리하는 곳에서는 예외에 따른 다른 처리가 필요할 수 있다. 하지만 공통 처리하는 한 곳만 변경하면 되서 영향 범위는 최소화 된다.

예외 포함과 스택 트레이스

@Test
void printEx() {
 Controller controller = new Controller();
 try {
 controller.request();
 } catch (Exception e) {
 //e.printStackTrace();
 log.info("ex", e);
 }
}

-예외를 전환할 때는 기존 예외를 포함해야 한다. 그렇지 않으면 스택 트레이스 확인할 때 심각한 문제가 발생한다.
-로그를 출력할 때 마지막 파라미터에 예외를 넣어주면 로그에 스택 트레이스를 출력할 수 있다.

• log.info("message={}", "message", ex) , 여기에서 마지막에 ex 를 전달하는 것을 확인할 수 있다. 이렇게 하면 스택 트레이스에 로그를 출력할 수 있다.
• log.info("ex", ex) 지금 예에서는 파라미터가 없기 때문에, 예외만 파라미터에 전달하면 스택
  트레이스를 로그에 출력할 수 있다.

[seyxxn]

수고하셨습니다 ㅎㅎ!!

[YuDeokRin]

정리 스타일 좀 바뀌셨군요