커머스 프로젝트를 진행하면서 예외처리에 대해 많이 고민했다.
처음에는 단순히 try-catch만 사용하면 되는 줄 알았는데,
실제로는 입력 예외, 잘못된 값 검증, 예외를 던지는 것과 잡는 것의 차이를 구분해야 한다는 것을 배웠다.
그리고 생각보다 예외처리를 해야하는게 굉장히 많다는걸 느꼈다
1. try-catch와 throw의 차이
처음에는 throw를 사용하면 예외를 “처리한 것”이라고 생각했다.
하지만 실제로는 throw는 예외를 직접 발생시키는 것이고,
그 예외를 실제로 처리하는 것은 try-catch라는 점을 이해했다.
예를 들어 Product.setPrice() 안에서 음수 가격이 들어오면
throw new IllegalArgumentException("가격은 0 이상이어야 합니다");처럼 예외를 던질 수 있다.
하지만 이렇게만 하면 예외가 발생한 것이지 처리된 것은 아니기 때문에,
이 메서드를 호출한 쪽에서 try-catch로 잡아주지 않으면 프로그램이 종료될 수 있다.
정리
throw = 예외 발생
try-catch = 예외 처리
2. 왜 setter 안에 throw를 넣는가?
처음에는
“가격을 입력받는 곳에서만 음수 체크를 하면 되는 거 아닌가?”
라고 생각했다.
음수면 메시지 출력
다시 입력받기
이렇게 처리하면 충분하다고 생각했다.
하지만 이 방식은 입력 받는 곳에서만 안전하고,
나중에 다른 곳에서 setPrice(-1000) 같은 코드가 실행되면
객체에 잘못된 값이 그대로 들어갈 수 있다는 문제가 있다.
그래서 setter 내부에서도 검증을 해야 한다는 점을 이해했다.
- throw로 메소드내에서 예외를 발생한것
- 처리는 try - catch로
정리
입력 단계의 검증 = 사용자 친화적인 처리
setter 내부의 검증 = 객체 자체를 안전하게 보호
즉, 두 군데에서 검증하는 것이 맞다.
3.예외처리는 디테일하게
커머스 과제를 하면서 모든예외처리를 Exception e 로만 처리했었다
try {
int num = sc.nextInt();
} catch (Exception e) {
System.out.println("잘못된 입력입니다");
}이렇게 하면 어떤 예외가 발생하든 모두 처리할 수 있어서 편하다고 생각했다.
하지만 이 방식에는 문제점이 있다는 것을 알게 되었다.
예를 들어:
- 숫자 입력 오류 → InputMismatchException
- 0으로 나누기 → ArithmeticException
- 잘못된 값 → IllegalArgumentException
이처럼 원인이 다른데도 모두 같은 메시지로 처리된다.
즉, 어떤 문제가 발생했는지 정확히 알 수 없다
Exception을 남발하면 문제 원인을 숨기게 된다
내상황에 딱 맞는 오늘 강의 내용이였던거같다
오늘 예외를 공부하면서
Exception도 하나의 클래스이며 상속 구조를 가진다는 것을 알게 되었다.
출저:https://reference-m1.tistory.com/246
예외 타입을 구분해서 처리하면 더 명확한 처리가 가능하다.
try {
int num = sc.nextInt();
} catch (InputMismatchException e) {
System.out.println("숫자를 입력해주세요");
} catch (Exception e) {
System.out.println("알 수 없는 오류입니다");
}깨달은점
Exception e는 모든 예외를 잡지만
→ 너무 넓은 범위라 디버깅이 어려워진다
가능하면 구체적인 예외 타입을 먼저 처리하고
→ 마지막에 Exception으로 처리하는 것이 좋다
