개발하다 보면 IDE가 빨간 줄로 경고해주죠?
"이건 반드시 처리하세요!" 라고 외치는 것 같은 그 느낌... 바로 Checked Exception입니다 😅
이 블로그에서는 자바의 예외 시스템 중 Checked Exception과 Unchecked Exception의 차이, 그리고 실무에서 어떻게 구분하고 적용하는 게 좋은지에 대해 제 개인적인 생각과 기록을 해보려 합니다
제가 생각하기에는 예외 설계는 코드의 품격을 나누는 기준이라고 생각하는데 다들 공감하시나요?
✅ 예외 처리, 왜 이렇게 나눠졌을까?
자바의 예외(Exception)는 크게 두 가지로 나뉩니다:
| 종류 | 예 | 처리 강제 여부 | 언제 발생? |
|---|---|---|---|
| Checked Exception | IOException, SQLException | O (컴파일 시 체크됨) | 외부 리소스와의 상호작용 등 예측 가능한 예외 |
| Unchecked Exception | NullPointerException, IndexOutOfBoundsException | X (컴파일러가 강제하지 않음) | 개발자의 실수, 논리 오류 등 예측 어려운 예외 |
🛠 Checked Exception이란?
- IDE가 빨간 줄로 싸악~ 감싸며 "예외처리하세요!"라고 알려주는 애들입니다.
FileReader,Socket,DB 연결등 외부와 연결되는 작업에서 발생할 수 있는 예외를 반드시 처리하도록 강제합니다.
public void readFile(String path) throws IOException {
FileReader reader = new FileReader(path);
// ... 파일 읽기
}이걸 처리하지 않으면? 컴파일조차 안 됩니다.
→ try-catch로 감싸거나, throws로 위임해야 하죠.
try {
readFile("hello.txt");
} catch (IOException e) {
System.out.println("파일을 읽는 중 문제가 발생했습니다: " + e.getMessage());
}🌀 Unchecked Exception이란?
- 컴파일러는 아무 말도 안 하지만... 런타임에 터지면 뇌정지 오는 예외들입니다 😇
NullPointerException,ArrayIndexOutOfBoundsException등 프로그래머 실수로 인한 오류가 대부분입니다.
String name = null;
System.out.println(name.length()); // NullPointerException→ IDE는 조용하지만, 런타임에서 갑자기 "응~ 터졌어~" 하는 예외들.
💡 언제 어떤 예외를 써야 할까?
📂 Checked Exception을 써야 할 때
- 외부 시스템과 통신: 네트워크, DB, 파일 시스템 등
- 실제로 실패 가능성이 높고, 호출한 쪽에서 복구할 수 있는 예외
예)
public void connectToDB() throws SQLException {
Connection conn = DriverManager.getConnection("jdbc:mysql://...");
// ... 쿼리 실행
}→ DB 연결 실패는 충분히 예상할 수 있는 시나리오고, 호출한 쪽에서 대처할 수 있어야 합니다.
🧠 Unchecked Exception을 써야 할 때
- 코드 작성자가 잘못했을 때: 로직 오류, null 접근, 잘못된 인덱스 등
- 복구할 수 없는 프로그래밍 실수일 경우
예)
public void divide(int a, int b) {
if (b == 0) throw new IllegalArgumentException("0으로 나눌 수 없습니다!");
System.out.println(a / b);
}→ 호출자가 잘못 썼다면 예외를 터뜨리고 알리는 게 낫습니다.
실무에서는 어떻게 하는게 좋을까? (개인적인 생각)
팀 내에서 다음과 같은 가이드를 정해두면 좋아요:
- 외부 리소스 접근은 반드시 Checked Exception으로 감싸기
- 비즈니스 로직에서 실패할 수 있는 조건은 커스텀 Exception으로 분리하기
- NullPointer나 IllegalArgument 같은 건 RuntimeException 상속받아 명확히 처리
- 중요한 도메인 오류는
CustomException extends RuntimeException형태로 구체화
예)
public class UserNotFoundException extends RuntimeException {
public UserNotFoundException(String userId) {
super("User not found: " + userId);
}
}❗ Error와 Exception은 뭐가 다를까?
| 항목 | Exception | Error |
|---|---|---|
| 상속 | Throwable → Exception | Throwable → Error |
| 의미 | 프로그램 내에서 발생할 수 있는 오류 | 시스템 레벨의 심각한 오류 |
| 예 | IOException, NullPointerException | OutOfMemoryError, StackOverflowError |
| 처리 권장 | ✅ | ❌ 거의 불가능 |
→ Error는 JVM이 죽기 직전의 신호라고 생각하세요. 가급적 복구를 시도하지 마세요.
🧪 결론: 예외에도 품격이 있다
예외는 단순한 try-catch가 아니라, 도메인 설계와 품질 보장의 핵심입니다.
예외를 적절하게 나누고, 적재적소에 사용하며, 팀 내 가이드를 정하는 것이 유지보수성과 디버깅 효율에 큰 영향을 줍니다.
🔥 예외를 잘 다루는 개발자는 팀의 든든한 방화벽이 될 수 있습니다.
Learner