

- 에러
- 예외
- Checked Exception
- Unchecked Exception
에러(Error)
Error는 애플리케이션이 정상적으로 복구하기 어려운, 주로 JVM 레벨의 심각한 문제를 나타낸다.
Exception과 형제 관계이지 부모-자식 관계가 아니라는 점이 중요하다.
문법적으로는 Error도 잡을 수 있다(catch (Error e)). 하지만 catch 하지 않는게 관례이다. 이유는 발생 시점에서 이미 JVM이나 시스템이 비정상 상태이기 때문에, 잡아서 복구할 수 없거나 오히려 문제를 숨기는 결과를 만든다. 그래서 Error는 모두 unchecked다. 컴파일러가 처리를 강제하지 않는다.
주요 하위 클래스로는 StackOverflowError(메모리 한계), OutOfMemoryError(힙 영역 공간 부족) 등이 있다.
예외(Exception)
java.lang.Exception 클래스와 하위 클래스들은 Error와 달리 애플리케이션 코드에서 예외가 발생하였을 경우에 사용된다. 그리고 Exception은 다시 체크 예외와 언체크 예외로 구분된다.
체크 예외(Check Exception)
체크 예외는 RuntimeException 클래스를 상속받지 않은 예외 클래스들이다. 체크 예외는 복구 가능성이 있는 예외이므로 반드시 예외를 처리하는 코드를 함께 작성해야 한다. 만약 예외를 잡지 않으면 컴파일 에러가 발생한다.
- 예시
- IOException
- SQLException
체크 예외는 개발자가 실수로 예외 처리를 누락하지 않도록 컴파일러가 도와준다.
빨간 밑줄이 코드에 뜨면서 Add exception to method signature 같은 메시지가 뜨는 것이 예외를 처리하기 위해 catch문으로 잡거나 throws를 통해 메소드 밖으로 던지라는 의미이다.
이 예외는 개발자가 실수로 예외 처리를 누락하지 않도록 컴파일러가 돕는다. 하지만, 개발자가 모든 체크 예외를 처리해야 하므로 번거롭고 신경쓰지 않고 싶은 예외도 처리해야 한다는 문제가 있다.
심지어 애플리케이션 개발에서 발생하는 예외들은 복구 불가능한 경우가 많다. 예를 들어 SQLException과 같은 체크 예외를 catch해도, 쿼리르 수정 후 재배포하지 않으면 복구되지 않는다.
그래서 실제 개발에서는 대부분 언체크 예외를 사용한다.
언체크 예외(Uncheck Exception)
언체크 예외는 컴파일러가 처리를 강제하지 않는 예외이다. try-catch로 잡거나 throws로 선언하지 않아도 컴파일이 통과한다.
- 왜 강제하지 않는가?
- 언체크 예외는 대부분 프로그래머의 실수에서 비롯된다. null 체크 누락, 배열 인덱스 초과, 0으로 나누기, 잘못된 인자 전달 등. 이런 건 코드를 올바르게 고쳐서 애초에 발생하지 않게 하는 것이 정답이지, try-catch로 매번 예외를 잡는 것이 비효율적이다.
모든 메소드에 NPE를 catch하면 코드가 감당되지 않는다. - 반면 체크 예외는 파일이 없거나 네트워크가 끊긴다던가 등 코드가 완벽해도 발생할 수 있는 상황이라, 컴파일러가 이건 대비하라고 강제하는 것이다.
- 언체크 예외는 대부분 프로그래머의 실수에서 비롯된다. null 체크 누락, 배열 인덱스 초과, 0으로 나누기, 잘못된 인자 전달 등. 이런 건 코드를 올바르게 고쳐서 애초에 발생하지 않게 하는 것이 정답이지, try-catch로 매번 예외를 잡는 것이 비효율적이다.
현대 자바/Spring 진영에서는 체크 예외보다 언체크 예외를 선호하는 경향이 강합니다. 체크 예외는 throws 선언이 호출 체인을 따라 계속 전파되면서 상위 계층이 하위 구현 세부사항(예: SQLException)에 의존하게 만들고, 의미 없는 try-catch나 무책임한 throws Exception을 유발하기 때문입니다. 그래서 Spring은 SQLException(체크) 같은 것을 DataAccessException(언체크) 계열로 감싸서 던지는 식으로 추상한다.
반대로 "체크 예외는 컴파일러가 처리를 보장해주는 안전장치"라며 옹호하는 입장(예: Effective Java는 복구 가능한 상황엔 체크 예외를 권한다)도 있어서, 무엇이 항상 옳다기보다 상황과 팀 컨벤션에 따라 판단하는 영역이다.
스프링 프레임워크가 제공하는 선언적 트랜잭션(@Transactional)안에서 발생하는 에러들은 체크일 시 롤백되지않고 언체크 예외일 시 롤백된다.(옵션으로 변경이 가능하다)
--
@Transactional 안에서 언체크, 체크 예외 실제 실험 내용 추가 예정
``` java
```
'언어(java, kotlin, python ...)' 카테고리의 다른 글
| [이펙티브 자바] 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라 / 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 (3) | 2025.07.30 |
|---|---|
| [이펙티브 자바] 아이템 03. private 생성자나 열거 타입으로 싱글턴임을 보증하라 (0) | 2025.07.29 |
| [이펙티브 자바] 아이템 02. 생성자에 매개변수가 많다면 빌더를 고려하라 (0) | 2025.07.28 |
| [이펙티브 자바] 아이템 01. 생성자 대신 정적 팩토리 메소드를 고려하라 (0) | 2025.07.25 |
| [Kotlin] 기본 문법 정리 (1) | 2025.03.27 |