벌써 추석이 다가오고, 졸업한 지 두 달이 다 되어간다. 면접을 조금씩 다녀보면서 여러 회사의 사무실에 들어가보니, 그곳에서 실제로 일하고 싶은 열망이 점점 더 커진다. 눈앞에 펼쳐진 현실을 직접 마주할수록, 내가 배우고 성장해야 할 것들이 얼마나 많은지도 느낀다.
하지만 포기하지 않고 한 걸음씩 나아간다면, 언젠가 내가 상상한 내일에 도달할 수 있을 것이라 믿는다.

자바의 예외(Exception)

자바에서는 예외를 크게 3가지로 나눈다.

1. 체크 예외(Checked Exception)
2. 에러(Error)
3. 언체크 예외(Unchecked Exception)

에러(Error)

시스템에서 복구가 불가능한 심각한 문제 발생 시 나타나는 상태

주로 하드웨어나 JVM 자체의 문제와 관련되며, 프로그램이 정상적으로 계속 실행되기 어렵다.

• 메모리 부족(OutOfMemoryError)
• 스택 오버플로우(StackOverflowError)

에러는 개발자가 직접 처리할 수 없는 경우가 많으며, 대부분 애플리케이션 레벨에서 처리하지 않고 시스템 차원에서 중단된다.

예외(Exception)

프로그램 실행 중 발생할 수 있는 예기치 않은 상황으로, 개발자가 적절히 처리하면 프로그램이 계속 실행될 수 있다.
예외는 코드 로직이나 외부 입력, 환경에 의해 발생하며, try-catch 블록 등을 통해 처리 가능하다.

• 배열의 범위를 벗어난 접근(ArrayIndexOutOfBoundsException)
• null 참조 변수 접근(NullPointerException)
• 파일이 존재하지 않는 경우(FileNotFoundException)

예외는 크게 체크 예외(Checked Exception)와 언체크 예외(Unchecked Exception)로 나눈다.

체크 예외는 컴파일 시 처리 여부를 강제하며, 언체크 예외는 런타임 시 발생합니다.

🤔 컴파일 시? 런타임 시?
🧩 컴파일(Compile)

• 코드를 실행하기 전, 즉 프로그램을 빌드(컴파일) 하는 순간
• 이때는 문법 오류나 타입 오류 같은 걸 미리 검사 가능
• 예를 들어, 존재하지 않는 메서드를 호출하거나, 자료형이 맞지 않으면 컴파일 시점에 에러가 발생
  👉 즉, “코드를 실행하기 전에 생기는 문제”
  ⚙️ 런타임 시 (Runtime)
• 프로그램이 실제로 실행되고 있는 동안을 의미
• 실행 중에 사용자의 입력, 네트워크, 파일 등 예상치 못한 상황으로 오류가 발생 가능
• 예를 들어, 0으로 나누거나(null 참조, 파일 없음 등) 하는 경우가 런타임 시점의 문제
  👉 즉, “코드를 실행하는 도중에 생기는 문제”

체크 예외(Checked Exception)

RuntimeException 의 하위 클래스가 아니면서 Exception 클래스의 하위 클래스

체크 예외는 반드시 에러 처리(try-catch, throw) 해야한다.

• FileNotFoundException
• ClassNotFoundException

언체크 예외(UnChecked Exception)

RuntimeException의 하위 클래스
에러 처리를 강제하지 않는다.
런타임시에 발생할 수 있는 예외

• ArrayIndexOutOfBoundsException
• NullPointerException

🤔 언체크 예외(UnChecked Exception)는 왜 에러처리를 안해도 되나요?

1️⃣ 프로그램의 논리적 실수로 발생하기 때문

언체크 예외는 대부분 개발자의 로직 오류로 인해 발생한다.

String s = null;
System.out.println(s.length()); //NullPointerException 발생

이 문제는 외부 요인이 아닌 코드 작성 시점에 충분히 방지할 수 있는 문제이므로,
컴파일러가 try-catch로 예외 처리를 강제하지 않는다.

2️⃣ 모든 코드에 try-catch를 강제하면 오히려 복잡해짐

만약 언체크 예외까지 모두 처리하도록 강제한다면,
코드가 불필요하게 길어지고 가독성이 떨어진다.

try {
    String s = null;
    System.out.println(s.length());
} catch (NullPointerException e) {
    e.printStackTrace();
}

이런 식으로 매번 감싸는 건 비효율적이기 때문에,
자바는 개발자가 스스로 방지할 수 있는 예외에 대해서는 자율적인 처리를 허용한다.

트랜잭션 롤백(Rollback) 시 체크 예외 vs 언체크 예외

구분	예시	기본 롤백 여부	설명	처리 방법
체크 예외 (Checked Exception)	IOException, SQLException	❌ 롤백되지 않음	컴파일 시점에 예외 처리가 강제됨. 주로 외부 요인(파일, 네트워크 등)으로 발생하며 복구 가능성이 있음.	명시적으로 rollbackFor 속성 지정 필요 → @Transactional(rollbackFor = Exception.class)
언체크 예외 (Unchecked Exception)	NullPointerException, IllegalArgumentException	✅ 자동 롤백됨	런타임 시점에 발생하며, 주로 개발자의 논리적 실수로 발생. 복구가 어렵고 프로그램 오류로 간주됨.	@Transactional 기본 설정으로 자동 롤백 처리

• 스프링의 기본 정책
  • @Transactional은 기본적으로 RuntimeException(언체크 예외)이나 Error가 발생하면 자동으로 롤백
  • 반면, Checked Exception은 자동으로 롤백되지 않는다
• 이유
  • 체크 예외는 복구 가능한 상황일 수 있어, 스프링이 자동으로 롤백하지 않도록 설계
  • 반면 언체크 예외는 복구가 어렵기 때문에 자동 롤백하는 것이 안전

---

@Transactional
public void process() throws IOException {
    // Checked Exception 발생 → 기본적으로 롤백되지 않음
    throw new IOException("파일 읽기 실패");
}

@Transactional
public void execute() {
    // Unchecked Exception 발생 → 자동 롤백됨
    throw new NullPointerException("널 참조 오류");
}

@Transactional(rollbackFor = Exception.class)
public void forceRollback() throws IOException {
    // Checked Exception이지만 명시적으로 롤백 설정
    throw new IOException("강제 롤백");
}

참고

• [Java] Java Exception