☕ 시작
백엔드, 프론트엔드에 상관없이 서비스를 개발하다보면, 가장 어려우면서 중요한 부분이 예외 또는 에러처리일 거라고 생각한다.
정상적인 흐름을 처리하는 데 3정도의 힘을 쓴다고 보면, 이 예외와 에러를 처리하는데 나머지 7을 쓴다고 볼 수 있을만큼 예외처리는 중요하고 어렵다.
이번 글에서는 Java의 예외객체를 살펴보고, 관련된 용어들도 총정리 해보도록 하겠다.
🧾 예외와 관련된 용어들
예외와 관련해서는 아래의 용어들을 많이 접하게 된다.
- 체크 예외: 컴파일러가 예외처리를 했는지 확인하는 예외
- 언체크 예외: 컴파일러가 확인하지 않는 예외
- 런타임 예외(에러): 컴파일이 된 후, 서비스를 구동하면서 발생되는 예외
- 컴파일 예외(에러): 컴파일할 때, 발생 또는 발견되는 예외밑에서 더 알게 되겠지만, 체크예외 == 컴파일 예외, 언체크 예외 == 런타임 예외이다.
용어만 들으면 더 혼란스럽다. 🙊
그림으로 정리해보도록 하자. 🤭
🔨 예외의 계층 구조
- Object: 자바의 모든 객체는 Object를 상속받고 있다. 예외 객체도 당연히 Object를 상속 받고 있다.
- Throwable: 예외에 대한 최상위 객체이다.
- Error: '메모리 부족'과 같은 시스템 또는 서버에서 발생하는 에러 또는 예외이다. 이런 예외는 개발자가 코드 상에서 다루지 않고, 다뤄도 안된다.
- Exception: 스프링과 같은 서비스 레벨에서 개발자가 다루게 되는 예외이다. Exception을 상속받은 모든 예외들은 컴파일 예외다. 단, RuntimeException은 제외
- RuntimException: 컴파일할 때 체크하지 않는(잡히지 않는) 에러이다. 어떤 비지니스 로직의 엣지 케이스에서 주로 발생한다.
예외의 종류들
그래서 어떤 종류의 예외들이 있는지 궁금할 수 있다.
예외의 종류들은 여기에서 한번 슥 보면 좋을 것 같다.
🔥 예외를 처리하는 방법
예외를 처리하는 법은 간단(?)하다. 예외는 잡거나 던지면 된다 😎
'예외를 잡는다'는 것은 예외가 발생할 수 있는 곳을 try catch문으로 감싸서, 해당 예외에 대한 처리를 catch문에서 처리하는 것이다.
try {
// 에러가 발생할 수도 있는 코드
} catch (IllegalArgumentException e) {
// e를 갖고 로깅을하고, 어쩌구 저쩌구
}'예외를 던진다'는 것은 예외가 발생할 수 있는 곳에서 바로 처리하지 않고 그 상위(부모)레벨의 객체 또는 함수한테 책임을 미루는 것이다.
try {
// 에러가 발생할 수도 있는 코드
} catch (IllegalArgumentException e) {
throw e; // 아 몰랑. 다른 곳에서 처리해
}예외는 기본적으로 위와 같은 식으로 처리를 하면 된다.
이 때, 들 수 있는 의문 🤔
-
내가
try catch로 하나 하나 다 해줘야된다고..? 언제 다 해?
-> 로직 1,2개면 몰라도 예외가 발생할 수 있는 곳 마다try catch로 감싸서 처리 해주면 실무에서는 감당안될만큼 복잡도가 올라간다.
코드의 양이 늘어나는 것은 당연하고, 코드의 가독성이 매우 떨어지고 코드 구조도 엄청 무너져버린다.
하지만 걱정하지 않아도 된다. 실무에서는 에러를 처리하는 라이브러리 또는 프레임워크의 힘을 빌려서 깔끔하게 처리한다. ㅎㅎ
(이 내용은 다른 글에서 제대로 다루는 것으로 하겠다.)
어찌됐든 예외를 처리하는 기본적인 규칙은잡거나 던지거나이라는 것을 잘 기억하면 된다. 🤭 -
잡지도 않고 던지지도 않으면 어떻게 되지?
-> 사실 개발자가 직접 안던져도 알아서 던져진다. 그래서 에러가 나는 곳에서 잡아서 처리하지 않으면, 상위로 계속 던져진다. 그렇게 최상위까지 던져지면 Java프로세스가 죽고 만다.
Spring에서는 잡지 않으면 톰캣 웹서버까지 타고 올라가고, 톰캣에서 에러 페이지 또는 메세지를 출력하게 된다. -
아무리 생각해도 에러가 한두개가 아닌데 어떻게 개발자가 어떻게 다 처리하냐!? 개발할 때, 외부 라이브러리 엄청나게 쓰는데, 그런 에러까지 다 어떻게 처리하냐!?
-> 맞다. 서비스 로직에서 사용자에게 알려줘야하는 에러들은 잡아서 처리한다.
그런데 뭐 네트워크가 어떻게 됐다든지 데이터베이스가 뭐 어쨌다든지... 뭐 그런 것은 사용자 입장에서는 알 바가 아니다. ㅎㅎ
그래서 이런 경우엔 사용자에게는 '우리 시스템에 이상이 있습니다. ㅈㅅ합니다' 이런식으로 에러 메세지를 주고, 내부적으로는 로깅이나 알림 시스템을 잘 구축해서 개발자가 빨리 알아차리고 수정해야한다(a.k.a 핫픽스🔥). 🤭
☕ 마무리
이번 글에서는 Java에 어떤 예외/에러객체들이 있는지, 어떻게 처리해야하는지등등 기본적인 것들에 대해서 알아보았다.
언제나 그렇듯 인생은 실전이기 때문에 실무에서는 더 철저하고 깔끔한 방법들로 프레임워크가 알아서 해준다ㅎ 처리를 한다.
그 내용에 대해서는 다른 글에서 더 알아보도록 하겠다.
오늘의 내용을 한 문장으로 정리하자면 "예외는 잡거나 던지거나"이다. 🤭
