F006 - Throwable, Exception, Error

✍️ 처음 프로그래밍을 접할 때고 그렇고, 현재까지도 그렇지만 콘솔창에 빨간 글씨가 나올 때나 갑자기 많은 문자들이 확 올라올 때 등골이 오싹한다.
처음 프로그래밍 습관을 잘못 들여서 그런지 예외나 에러가 발생하면 왜 발생했는지 따져보기 보단 일단 치워버리려고 메세지를 복사해서 구글창에 검색하고 남들이 해결한 코드를 그대로 복사, 붙혀넣기 바빴던 것 같다.
자바의 신을 읽으면서 예외에 대해 다시 접하게 됐는데 이번 기회에 예외 공포증을 이겨보려고 한다.

---

예외의 조상

Reference Type 챕터에서 공부했던 내용과 연결해서, 모든 클래스의 조상은 java.lang.Object(이하 Object 클래스)이다. 예외에 속한 클래스들도 이 조건에서 벗어나지 않는다. 다만 모든 예외들의 아버지라고 할 수 있는 존재가 있는데, 그 클래스는 바로 java.lang.Throwable(이하 Throwable 클래스)이다.

The Throwable class is the superclass of all errors and exceptions in the Java language. Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement.
- Oracle Java 8 API

API 문서를 들여다보면 Throwable 클래스에 대한 개요에 대한 설명이 나와 있는데, 간단히 서술하자면 Throwable 클래스는 Java 에서 일어나는 모든 에러와 예외에 대한 SuperClass(최상위 클래스, 모든 에러와 예외가 가지는 공통 분모)이다. Throwable 클래스를 상속 받는 클래스들만 JVM에 의해 예외 혹은 에러 발생 시, throw 처리된다.

Throwable 클래스도 기본 생성자를 통해 선언 가능하며,
String을 매개 변수로 받는 생성자를 통해 직접 예외 메세지를 지정해 선언할 수 있다.

• Throwable()
• Throwable(String message)

또한, Object 클래스를 상속 받다보니 Object 클래스의 메소드를 Overriding 하여 재정의한 메소드도 존재한다. 대부분의 메소드는 예외 혹은 에러 발생 시 공통적으로 필요한 것들만 만들어져있다.

• toString()

Throwable 클래스에는 대표적인 하위 클래스 두 개가 존재하는데, 앞에서도 많이 언급했던 java.lang.Error(이하 Error 클래스)와 java.lang.Exception(이하 Exception 클래스)이다.

이 두 클래스는 서로 다른 차이가 존재하기 때문에 Throwable 클래스에서 갈라졌다고 이해하면 편하며 이 두 클래스에 대해 알아보자.

Error / Exception

Error

Error 클래스는 IOError, ThreadDeath, VirtualMachineError 등 Error 클래스를 상속받는 클래스의 이름을 보면 알 수 있듯 개발자의 손을 벗어난 프로그램 바깥에서 발생한 예외를 뜻한다. 때문에 Error 클래스는 프로세스에 영향을 미친다. 그렇기 때문에 Error 클래스 및 자식 클래스는 비정상적인 조건 속에서 발생하기 때문에 try ~ catch 구문으로 해결 할 수 없다. (애플리케이션 단에서 해당 이슈에 대해 개발자가 처리하지 않아도 된다.)

Exception

개발하면서 가장 많이 만나게 되고, 만나기 두려운 존재가 바로 Exception 클래스이다. Exception 클래스는 Error 클래스와 다르게 try ~ catch 구문으로 해당 예외를 잡아 처리 가능하다. 때문에 이에 대해 두 가지로 나뉘어 지는데, Checked Exception과 Runtime Exception(+ Unchecked Exception)이다.

Runtime Exception(+ Unchecked Exception)

해당 영역에 속하는 예외 클래스는 RunTime Exception 클래스를 포함한 자식 클래스들을 뜻한다. 이들은 프로그램을 실행하는 중에 발생하는 예외의 집합으로 NullPointerException, IndexOutOfBoundException 등이 이에 속한다.(엄밀히 말하면 이 예외 클래스들은 Unchecked Exception 클래스들이다.)

이들의 특징은 명시적으로 처리를 하지 않아도 된다. 왜냐하면 해당 예외 클래스들은 컴파일 할 때가 아닌 실행 단계에서 발생하는 예외들이기 때문이다. 즉, throws 예약어를 이용해 메소드에서 해당 예외 발생 시 책임 회피를 하지 않아도 되고, try ~ catch 구문을 통해 굳이 예외 발생 시에 대한 대안책을 세우지 않아도 된다는 말이다. 다만, 애플리케이션 개발을 진행하면서 자주 발생하는 Unchecked Exception에 대해 적절한 대비를 해놓지 않으면 완벽하다고 생각한 코드라 할지라도 언젠가는 만나게 되더라.

여기에 속하는 예외 클래스들은 트랜잭션 시, RollBack을 수행한다는 점도 기억해놓는 것이 좋다.

221126 수정!
백기선님의 [Effective Java] - Item 2 > IllegalArgumentException 수업을 들은 뒤, 과거에 작성한 내용이 제가 알고 있던 부분이 잘못된 내용이라 이에 대해 수정합니다. 죄송합니다.

RuntimeException 이 RollBack 을 수행한다는 내용은 Spring Framework 의 기본 설정으로 해당 Exception 이 아니더라도 개발자가 원하는 방향으로 설정 가능합니다. 또한, 여러 블로그(저를 포함한😢)에서 이에 대해 설명할 때 등장하는 Transaction 의 의미는 명확히 어떤 의미인지 알 수 없습니다. Database Transaction 인지, Message Queue Transaction 인지 알 수 없기 때문에 옳지 못한 내용입니다. 

그렇다면 Spring Framework 에서는 왜 RuntimeException 발생 시 기본적으로 Transaction 을 RollBack 하도록 만들었을까요?
이는 RuntimeException 과 그의 서브 클래스들은 예상 가능한 범위에 속하지 않아 어떠한 경우는 대비하지 않을 수도 있어 Transaction 발생 시 RollBack 을 하는 것 입니다.

Checked Exception

해당 영역에 속하는 예외 클래스는 컴파일 시에 발생하는 예외 클래스의 집합으로, Runtime Exception 에 속한 클래스를 제외한 모든 Exception 클래스를 뜻한다.

여기에 속한 대표적인 예외 클래스로는 IllegalClassFormatException, SQLException, IOException 등이 존재하는데, 이들은 try ~ catch 구절이나 throws 예약어 등으로 꼭 메소드 단에서 처리를 해줘야 한다. 왜냐하면 Checked Exception 클래스들은 컴파일 시에 발생하기에 예외를 처리해주지 않으면 컴파일이 되지 않기 때문이다.

그러한 이유로 Checked Exception에 속한 클래스들은 RollBack을 수행하지 않는데, 아직 검색 실력의 부족과 지식의 끈이 짧아서 그 이유에 대해 정확히 파악하지 못했다. 조금 더 찾아보고 해당 부분 개선해야겠다!

---

💁‍♂️ 해당 부분에 대해 공부하다 보니 많은 블로그에서 예외 처리 전략과 연결되어 설명하고 있었는데, 대부분 토비의 스프링(성경)을 읽고 작성하신 글이 대부분이였다! 조금 더 성장하고, 글만 읽어도 충분히 이해가 될 때 꼭 토비의 스프링 독서에 도전해봐야겠다!

---

참고 사이트

Java Platform SE 8

Checked Exception을 대하는 자세 - Yun Blog | 기술 블로그

Java 예외(Exception) 처리에 대한 작은 생각