[Java] 예외처리 - 예외 계층 구조, 예외 처리 기본 룰

이번에 스프링 예외 처리를 공부하던 중, 자바 기본 예외 처리를 복습하고자 글을 작성한다.

예외처리가 왜 필요한지 간단하게 한줄 요약하자면, 자바 내부에서 로직을 처리하면서 다양한 예외 및 상황이 발생할 수 있는데, 이때 If 문으로 모두 연결하여 작성하게 되면, 정상 흐름과 예외 방지 로직이 섞여 코드를 이해하고 유지 보수 하기 힘들다.

이를 위해 예외를 처리하기 위한 매커니즘이 자바 예외 처리 기능인데, 이는 프로그램의 안정성과 신뢰성을 높이는데 중요한 역할을 한다.

그래서 우리가 흔히 보는 다음 키워드들이 예외처리를 위해 존재하는 예약어들이다 -> try - catch - finally / throw , throws

---

예외 계층 구조

자바 예외는 위와 같은 계층 구조를 가졌는데, 기본적으로 예외도 객체이기 때문에 Object의 자식 클래스이다.

그리고 예외를 대표하는 클래슨느 Throwable 클래스이다. 그의 자식이 Exception과 Error 로 나뉘어지는데, Error 예외는 S/W적으로 잡기 어려운 예외 임으로 개발자가 딱히 할 수 있는게 없다. (로그 정도 남기기?)

이외 애플리케이션 최상 예외 클래스인 Exception과 이의 자식으로 RuntimeException으로 구성되는데, 각각 체크예외, 언체크 예외(런타임)으로써 다음 포스팅으로 따로 다루겠다.

간단하게만 설명하면 Exception 자신과 그의 자식 클래스 예외 들을 모두 컴파일러가 체크할 수 있는 예외이다.

다만 여기서 RuntimeException만 제외하는데, 이름에서도 볼 수 있다시피 런타임에 발생하는 예외기 때문에 컴파일러가 잡을 수 없다. 그래서 런타임 예외와 그 자식 예외들은 모두 언체크 예외라고 부른다.

얘웨 췤크 !

즉, 체크 예외와 언체크 예외를 구분하는 방법은 컴파일러가 체크할 수 있는지를 기준으로 하면 된다.

 

---

체크 예외 / 언체크 예외를 다루는 전략

체크 예외는 개발자가 명시적으로 처리해야한다. 안하면 컴파일 오류남.

언체크 예외는 개발자가 명시적으로 처리하지 않아도 된다. 애초에 런타임에 터지는거라 미리 처리할 수도 없을 듯.

 

예외도 상속관계가 적용됨

예외도 부모타입 예외를 catch하면 자식 예외까지도 잡힌다.

즉 Throwable 예외부터 하나씩 내려가며 잡으면 될듯.

---

예외 처리 기본 규칙

예외는 반드시 try-catch로 잡아서 처리하거나, 호출한 클래스로 다시 넘겨서 거기서 처리하든 다시 넘기든 해야한다.

즉 처리하거나 , 처리할 수 없으면 밖으로 던져야한다.

위 예시를 보면, client에서 예외가 터지면, 본인이 잡거나 자신을 호출한 service로 다시 예외를 넘겨야한다.

Service 에서 예외를 잡았으니 애플리케이션은 다시 정상흐름으로 동작한다.

 

예외를 던지는 예시를 보자.

수리남 같은게 그 누구도 똥을 싸재껴 놓고 빤쓰도 안빨려고하는 그런 모습을 보여준다ㅋㅋ.

이러면 결국 최종 목적지인 main() 까지 예외가 올라와서 시스템이 종료된다.