Day 22 — 예외 처리 ② 던지고 전파 (throw / throws, checked vs unchecked)

지난 시간 우리는 예외를 try-catch 로 "잡는" 법을 배웠어요. ObjectBox·Repository·Stack 이 던진 예외를 우리가 받아냈죠. 그런데 가만 보면 이상한 점이 있었어요. Day 20 에서 만든 Repository.findById 는 없는 id 를 만나면 throw new IllegalArgumentException(...) 으로 예외를 직접 "던지고" 있었고, Stack.pop 도 빈 스택에서 throw new IllegalStateException(...) 을 던졌어요.

그러니까 우리는 이미 예외를 던지는 코드를 적어두고도, "잡는" 쪽만 배웠던 거예요. 오늘은 그 반대편, 예외를 직접 던지는(throw) 쪽으로 넘어가요.

오늘 주인공은 throw(예외를 직접 던지기)와 throws(예외를 호출자에게 전파하기) 두 가지예요. 지난 시간 잠깐 미뤄둔 checked 와 unchecked 의 진짜 차이도 정면으로 다뤄요. 그리고 "이 사고는 내가 잡고, 저 사고는 위로 올려보낸다" 는 판단까지 익혀요. 지난 시간이 받는 쪽이었다면, 오늘은 던지는 쪽이 되는 거예요. 자, Day 22 시작해봐요!

🎯 학습 목표

• throw 로 내가 직접 예외를 던져서 잘못된 값을 막을 수 있어요.
• checked 예외와 unchecked 예외의 차이(컴파일러가 처리를 강제하는지)를 구분할 수 있어요.
• throws 로 예외를 호출자에게 전파할 수 있고, throw 와 throws 의 차이를 설명할 수 있어요.
• 아무도 안 잡은 예외가 콜스택을 거슬러 올라가는 과정을 그림으로 그릴 수 있어요.
• "여기서 잡을까, 위로 던질까" 를 상황에 따라 판단할 수 있어요.
• 던지고(throw)·전파하고(throws)·받는(try-catch) 전체 흐름을 하나로 엮을 수 있어요.

Step 1: throw — 이제 내가 직접 던진다

지난 시간엔 예외를 "받는" 쪽이었어요. 오늘은 반대로, 내가 직접 예외를 "던지는" 쪽이에요. 그런데 사실 우리는 던지는 코드를 이미 본 적이 있어요.

Day 20 에서 만든 Repository.findById 를 다시 볼게요. 없는 id 를 찾으면 이렇게 했었죠.

// com/instagram/javabasic/generic/Repository.java (Day 20)
public T findById(Long id) {
    T found = store.get(id);
    if (found == null) {
        throw new IllegalArgumentException("id " + id + " 에 해당하는 항목이 없어요.");
    }
    return found;
}

throw new IllegalArgumentException(...) — 이게 바로 예외를 직접 던지는 코드예요. 지난 시간엔 이 메서드를 try-catch 로 받기만 했는데, 오늘은 이 던지는 문장 자체를 우리가 써봐요.

throw(스로우, "던지다") 는 "여기서부터는 정상이 아니야!" 하고 예외를 직접 만들어 던지는 명령이에요. 문법은 간단해요.

 throw new 예외종류("무엇이 잘못됐는지 메시지");
        └──┬──┘     └──────────┬──────────────┘
       예외 객체를         왜 잘못됐는지
       하나 새로 만들어     설명을 담아서

이 한 줄이 실행되면 두 가지 일이 한 번에 일어나요. 첫째, 메서드가 그 줄에서 즉시 멈춰요(뒤에 코드가 있어도 실행 안 됨). 둘째, 만든 예외가 이 메서드를 부른 쪽으로 튀어 올라가요.

이제 직접 던져볼게요. 인스타그램 캡션(게시물에 다는 글) 길이를 검사하는 코드예요. 인스타는 캡션을 2,200자까지만 허용해요. 한도를 넘으면 그냥 통과시키지 않고 throw 로 막을 거예요.

// com/instagram/javabasic/exceptionbasic/ThrowStatement.java
public class ThrowStatement {

    // 인스타 캡션 최대 길이예요. 2200자까지만 쓸 수 있어요.
    public static final int MAX_CAPTION_LENGTH = 2200;

    // 캡션을 검사해서 통과하면 그대로 돌려주고, 규칙에 어긋나면 throw 로 막아요.
    // 빈 캡션이거나 한도를 넘으면 IllegalArgumentException 을 던져요.
    public String validateCaption(String caption) {
        if (caption == null || caption.isEmpty()) {
            throw new IllegalArgumentException("캡션이 비어 있어요.");
        }
        if (caption.length() > MAX_CAPTION_LENGTH) {
            throw new IllegalArgumentException("캡션은 2200자까지예요. 지금은 " + caption.length() + "자.");
        }
        return caption;
    }
}

흐름을 따라가볼게요. 캡션이 비어 있으면 첫 번째 if 에서 throw 가 실행돼 메서드가 즉시 멈춰요. 길이가 2,200자를 넘으면 두 번째 if 에서 막혀요. 두 검사를 다 통과해야 비로소 마지막 줄 return caption; 까지 도착해요.

 validateCaption("...") 안에서 벌어지는 일

   caption 비었나?  ──예──▶ throw! 💥 (여기서 멈춤, 위로 튐)
        │ 아니오
        ▼
   2200자 넘나?    ──예──▶ throw! 💥 (여기서 멈춤, 위로 튐)
        │ 아니오
        ▼
   return caption  ✅ (검사 통과, 무사히 돌려줌)

이제 main 에서 두 경우를 다 확인해볼게요. 정상 캡션과 한도를 넘긴 캡션을 둘 다 넣어봐요. 던진 예외는 지난 시간 배운 try-catch 로 받아요.

public static void main(String[] args) {
    ThrowStatement validator = new ThrowStatement();

    // 정상 — 짧은 캡션은 그대로 통과해요.
    String ok = validator.validateCaption("오늘 점심 인증 #맛집");
    System.out.println("통과한 캡션: " + ok);

    // 사고 — 한도를 넘는 캡션은 throw 로 막혀요. try-catch 로 받아 메시지를 보여줘요.
    StringBuilder tooLong = new StringBuilder();
    for (int i = 0; i < MAX_CAPTION_LENGTH + 1; i++) {
        tooLong.append("가");
    }
    try {
        validator.validateCaption(tooLong.toString());
    } catch (IllegalArgumentException e) {
        System.out.println("막혔어요: " + e.getMessage());
    }
}

실행하면 정상 캡션은 "통과한 캡션: ..." 이 찍히고, 2,201자짜리 긴 캡션은 throw 에 막혀 "막혔어요: 캡션은 2200자까지예요. 지금은 2201자." 가 나와요. 우리가 던진 예외를, 우리가 잡은 거예요.

💡 튜터의 결론

throw new 예외종류("메시지") 한 줄이면 내가 직접 예외를 던질 수 있어요. 그 줄에서 메서드는 즉시 멈추고, 예외는 부른 쪽으로 튀어 올라가요. Day 20 의 Repository.findById·Stack.pop 도 사실 이렇게 예외를 던지고 있었어요. 잘못된 값을 그냥 통과시키지 않고 "이건 안 돼요!" 하고 분명히 막는 게 throw 의 역할이에요.

Step 2: checked vs unchecked — 컴파일러가 강제하는 예외, 안 하는 예외

지난 시간 예외의 족보를 그릴 때 제가 한 가지를 미뤄뒀어요. 예외에는 사실 성격이 다른 두 종류가 있는데, 그 차이를 오늘 정리해요.

두 종류의 이름은 unchecked(언체크) 예외와 checked(체크) 예외예요. 이름이 어려워 보이지만 차이는 딱 하나예요. 컴파일러가 "이 예외 처리했어?" 하고 강제로 확인하느냐, 안 하느냐.

                 Throwable (맨 윗조상)
                 ├── Error                 (손쓸 수 없는 심각한 사고)
                 └── Exception  ◀── 이 갈래가 기본은 checked (처리 강제)
                     └── RuntimeException ◀── 이 아래만 unchecked (강제 안 함)

지난 시간 만난 IllegalArgumentException·IllegalStateException·ClassCastException 은 모두 RuntimeException 자손이었죠? 그래서 전부 unchecked 예요. 반대로 Exception 바로 아래(RuntimeException 을 거치지 않는) 예외들은 checked 예요.

말로만 하면 안 와닿으니 두 종류를 나란히 만들어 차이를 직접 느껴볼게요.

// com/instagram/javabasic/exceptionbasic/CheckedVsUnchecked.java
public class CheckedVsUnchecked {

    // unchecked 예외 — throws 선언이 없어요. 그래도 컴파일이 돼요.
    // 나이가 음수면 IllegalArgumentException 을 던져요.
    public void uncheckedExample(int age) {
        if (age < 0) {
            throw new IllegalArgumentException("나이는 음수일 수 없어요: " + age);
        }
        System.out.println("나이 확인 완료: " + age);
    }

    // checked 예외 — 메서드 뒤에 throws Exception 을 꼭 적어야 컴파일돼요.
    // 컴파일러가 "이 예외는 호출하는 쪽이 반드시 처리해야 해" 라고 강제하는 거예요.
    public void checkedExample(boolean fail) throws Exception {
        if (fail) {
            throw new Exception("처리를 강제하는 checked 예외예요.");
        }
        System.out.println("checked 작업 성공!");
    }
}

두 메서드를 비교해보세요. uncheckedExample 은 IllegalArgumentException(unchecked)을 던지는데 메서드 뒤에 아무 선언이 없어요. 그래도 컴파일이 잘 돼요.

그런데 checkedExample 은 Exception(checked)을 던지는데, 메서드 이름 뒤에 throws Exception 이 붙어 있죠? 이게 없으면 컴파일러가 빨간 줄을 그으며 "이 checked 예외를 처리하든지, 넘기든지 둘 중 하나는 해!" 하고 막아요. 컴파일조차 안 되는 거예요.

 같은 throw 인데 컴파일러 반응이 달라요

   unchecked (IllegalArgumentException)
     throws 선언 없음  →  컴파일 OK ✅  (강제 안 함)

   checked (Exception)
     throws 선언 없음  →  컴파일 에러 ❌  (처리하라고 강제!)
     throws Exception  →  컴파일 OK ✅

main 에서도 이 차이가 그대로 드러나요.

// checkedExample 을 부르려면 main 에도 throws Exception 이 필요해요(전파).
public static void main(String[] args) throws Exception {
    CheckedVsUnchecked demo = new CheckedVsUnchecked();

    // unchecked — 정상 호출. throws 없이 그냥 부르면 돼요.
    demo.uncheckedExample(25);

    // checked — fail=false 면 성공해요. throws Exception 이 있어 그냥 부를 수 있어요.
    demo.checkedExample(false);
}

main 뒤에도 throws Exception 이 붙은 게 보이시죠? checked 예외를 던지는 checkedExample 을 부르니까, main 도 "나도 이 예외를 안 잡고 넘길래" 라고 선언해야 컴파일이 돼요. unchecked 인 uncheckedExample 은 그런 선언 없이 그냥 불러요.

💡 튜터의 결론

예외는 두 종류예요. RuntimeException 자손은 unchecked — 컴파일러가 처리를 강제하지 않아요. 그 외 Exception 자손은 checked — 메서드에 throws 를 적거나 try-catch 로 잡지 않으면 컴파일조차 안 돼요. unchecked 는 "내 실수", checked 는 "바깥 사정으로 실패할 수 있는 일" 이라고 기억하면 편해요.

Step 3: throws — 안 잡고 호출자에게 넘기기

예외를 만난 메서드에는 두 가지 선택지가 있어요.

1. 내가 직접 try-catch 로 잡는다 (지난 시간에 배운 것)
2. 내가 안 잡고 "호출한 너가 처리해" 하고 넘긴다 (이번 시간!)

2번을 하려면 Step 2 에서 슬쩍 본 throws 를 써요. throws(스로우즈)는 메서드 이름 뒤에 붙여서 "이 메서드는 이런 예외를 넘길 수 있어요" 라고 알리는 표지판이에요.

   void follow(String me, String target) throws Exception {
                                          └──────┬───────┘
                                    "나는 이 예외를 안 잡고
                                     부른 쪽에 넘길 수 있어"
                                     라는 표지판

표지판을 붙여두면, 이 메서드 안에서 예외를 잡지 않아도 돼요. 대신 이 메서드를 부른 쪽이 try-catch 로 받든지, 아니면 그쪽도 throws 로 또 넘기든지 해야 해요.

자기 자신을 팔로우하려는 경우를 막는 코드로 확인해볼게요. 인스타에서 내가 나를 팔로우할 수는 없잖아요? 그런데 이번엔 그 예외를 follow 메서드 안에서 잡지 않고, throws 로 호출자에게 넘겨요.

// com/instagram/javabasic/exceptionbasic/ThrowsDeclaration.java
public class ThrowsDeclaration {

    // 팔로우 — 자기 자신은 팔로우할 수 없어요.
    // 여기서 잡지 않고 throws Exception 으로 호출한 쪽에 넘겨요.
    public void follow(String me, String target) throws Exception {
        if (me.equals(target)) {
            throw new Exception("자기 자신은 팔로우할 수 없어요.");
        }
        System.out.println(me + " 님이 " + target + " 님을 팔로우했어요.");
    }
}

follow 메서드는 자기 자신을 팔로우하려 하면 throw new Exception(...) 으로 던지기만 하고, try-catch 로 잡지 않아요. 대신 throws Exception 표지판을 붙였죠. "나는 이 예외를 안 잡으니, 부른 쪽에서 처리해" 라는 뜻이에요.

여기서 throw 와 throws 가 같이 등장하는데, 한 글자 차이라 정말 헷갈려요. 확실히 구분하고 가요.

 throw  vs  throws  — 한 글자 차이, 완전히 다른 역할

   throw  (s 없음)  : 문장. 예외를 지금 "던지는" 동작.
                      → throw new Exception("...");

   throws (s 있음)  : 선언. 메서드가 예외를 "넘길 수 있다" 는 표지판.
                      → void follow(...) throws Exception { ... }

그러면 이 예외는 누가 처리할까요? follow 를 부른 main 이에요. follow 가 throws 로 넘겼으니, main 이 try-catch 로 받아야 해요.

public static void main(String[] args) {
    ThrowsDeclaration service = new ThrowsDeclaration();

    // 정상 — 서로 다른 사람이라 팔로우가 성공해요.
    // follow 가 예외를 넘길 수 있으니, 부른 쪽인 여기서 try-catch 로 받아요.
    try {
        service.follow("minji", "jaehoon");
    } catch (Exception e) {
        System.out.println("실패: " + e.getMessage());
    }

    // 사고 — 자기 자신을 팔로우하면 follow 가 던진 예외가 여기까지 넘어와요.
    try {
        service.follow("minji", "minji");
    } catch (Exception e) {
        System.out.println("실패: " + e.getMessage());
    }
}

"minji" 가 "jaehoon" 을 팔로우하면 성공 메시지가 찍히고, "minji" 가 "minji" 를 팔로우하면 follow 가 던진 예외가 main 까지 넘어와 "실패: 자기 자신은 팔로우할 수 없어요." 가 나와요. 던지는 곳(follow)과 잡는 곳(main)이 분리된 거예요.

💡 튜터의 결론

예외를 만난 메서드는 직접 잡거나(try-catch), 안 잡고 넘기거나(throws) 둘 중 하나를 골라요. throws 는 메서드 뒤에 붙는 "이 예외를 넘길 수 있어요" 표지판이에요. throw(동작, s 없음)와 throws(선언, s 있음)는 한 글자 차이지만 역할이 완전히 달라요. 넘긴 예외는 결국 부른 쪽이 책임지고 처리해요.

Step 4: 예외가 콜스택을 거슬러 오른다 — 전파의 그림

Step 3 에서 follow 가 던진 예외가 main 까지 "넘어왔다" 고 했죠. 그런데 메서드가 여러 겹으로 깊게 호출되면, 예외는 정확히 어디로 갈까요? 이번엔 그 이동 경로를 그림으로 그려봐요.

먼저 메서드가 메서드를 부르는 순서를 콜스택(call stack, 호출 더미)이라고 해요. 접시를 쌓듯, 메서드를 부를 때마다 위로 한 칸씩 쌓여요.

 콜스택 — 메서드를 부를 때마다 한 칸씩 쌓여요

   main 이 showPage 를 부르고
   showPage 가 renderProfile 을 부르고
   renderProfile 이 loadProfileImage 를 불러요

        ┌─────────────────────┐ ← 가장 깊은 곳 (마지막에 쌓임)
        │  loadProfileImage   │
        ├─────────────────────┤
        │  renderProfile      │
        ├─────────────────────┤
        │  showPage           │
        ├─────────────────────┤
        │  main               │ ← 맨 아래 (제일 먼저 쌓임)
        └─────────────────────┘

이렇게 깊이 들어간 상태에서, 가장 깊은 loadProfileImage 가 예외를 던지면 어떻게 될까요? 중간 메서드들이 잡지 않으면, 예외는 쌓인 순서를 거꾸로 거슬러 올라가요. 이걸 전파(propagation)라고 해요.

프로필 이미지를 불러오는 3단 호출로 확인해볼게요. 이번엔 unchecked 예외(IllegalStateException)를 써서, throws 선언 없이도 예외가 위로 올라가는 모습을 봐요.

// com/instagram/javabasic/exceptionbasic/CallStackPropagation.java
public class CallStackPropagation {

    // 가장 깊은 메서드 — 실제로 예외가 시작되는 곳이에요.
    // 주소가 없으면 IllegalStateException 을 던져요(unchecked 라 throws 가 필요 없어요).
    public String loadProfileImage(String url) {
        if (url == null || url.isEmpty()) {
            throw new IllegalStateException("프로필 이미지 주소가 없어요.");
        }
        return url;
    }

    // 중간 메서드 — 예외를 잡지 않고 그대로 통과만 시켜요. 예외는 여기를 그냥 지나가요.
    public String renderProfile(String url) {
        return loadProfileImage(url);
    }

    // 또 다른 중간 메서드 — 역시 잡지 않고 통과만. 예외가 한 칸 더 위로 올라가요.
    public String showPage(String url) {
        return renderProfile(url);
    }
}

renderProfile 과 showPage 를 보세요. 둘 다 try-catch 가 없어요. 그냥 다음 메서드를 부르기만 해요. 그래서 가장 깊은 loadProfileImage 가 예외를 던지면, 두 중간 메서드는 그저 통과 통로가 되고 예외는 계속 위로 올라가요.

 loadProfileImage 가 throw! 💥  예외가 거슬러 올라가요

   loadProfileImage  💥 throw  ──┐
   renderProfile     (안 잡음)   │ 예외가
   showPage          (안 잡음)   │ 위로
   main              🧤 catch! ◀─┘ 여기서 드디어 잡힘

main 에서 try-catch 로 받으면, 비로소 예외가 멈춰요.

public static void main(String[] args) {
    CallStackPropagation page = new CallStackPropagation();

    // 정상 — 주소가 있으면 맨 깊은 곳에서 끝까지 잘 돌아와요.
    System.out.println("정상: " + page.showPage("profile.jpg"));

    // 사고 — null 을 넣으면 맨 깊은 loadProfileImage 에서 예외가 터져
    // renderProfile → showPage 를 거슬러 올라와 여기 main 의 catch 에서 잡혀요.
    try {
        page.showPage(null);
    } catch (IllegalStateException e) {
        System.out.println("맨 위(main)에서 잡았어요: " + e.getMessage());
    }
}

page.showPage(null) 을 부르면, 호출은 showPage → renderProfile → loadProfileImage 순서로 깊이 내려갔다가, 예외는 그 반대로 거슬러 올라와 main 에서 잡혀요. 만약 main 마저 안 잡았다면? 예외는 프로그램 밖까지 튀어나가 프로그램이 멈추고 빨간 에러 메시지가 출력돼요.

💡 튜터의 결론

예외를 아무도 안 잡으면, 호출한 순서를 거꾸로 거슬러 올라가요. 이게 전파(propagation)예요. 중간 메서드들이 잡지 않으면 그냥 통과 통로가 되고, 누군가 try-catch 로 잡을 때까지 계속 올라가요. 끝까지 아무도 안 잡으면 프로그램이 멈춰요. unchecked 예외는 throws 선언 없이도 이렇게 자동으로 전파돼요.

Step 5: 잡을 곳 vs 던질 곳 — 예외 처리 전략

이제 가장 중요한 판단을 배워요. 예외를 만났을 때 "여기서 잡을까, 아니면 위로 던질까?" 를 어떻게 정할까요?

기준은 의외로 단순해요. "내가 지금 이 문제를 제대로 해결할 수 있는가?" 예요.

• 해결할 수 있으면(어떻게 복구할지 안다면) → 여기서 잡아요.
• 해결할 수 없으면(무엇이 옳은 대응인지 모른다면) → 잡지 말고 위로 던져요. 더 잘 아는 쪽이 처리하게요.

같은 일을 두 방식으로 나란히 만들어 비교해볼게요. 사용자가 입력한 "보고 싶은 게시물 개수" 글자를 숫자로 바꾸는 상황이에요. 자바의 Integer.parseInt 는 숫자가 아닌 글자를 만나면 NumberFormatException 을 던져요.

// com/instagram/javabasic/exceptionbasic/HandleOrThrow.java
public class HandleOrThrow {

    // 던지는 쪽 — 숫자로 못 바꾸면 NumberFormatException 이 그대로 위로 전파돼요.
    // 여기선 "무엇이 옳은 기본값인지" 를 모르니 굳이 잡지 않고 호출자에게 맡겨요.
    public int parseLimit(String raw) {
        return Integer.parseInt(raw);
    }

    // 잡는 쪽 — parseLimit 을 try-catch 로 감싸, 변환이 실패하면 기본값 30 으로 복구해요.
    // 인스타 해시태그 한도와 같은 30 을 안전한 기본값으로 써요.
    public int parseLimitOrDefault(String raw) {
        try {
            return parseLimit(raw);
        } catch (NumberFormatException e) {
            return 30;
        }
    }
}

두 메서드의 태도가 완전히 달라요.

parseLimit 은 "던지는 쪽" 이에요. 숫자 변환만 할 뿐, 변환이 실패했을 때 무엇이 옳은 값인지 몰라요. 그래서 굳이 잡지 않고 예외를 그대로 위로 흘려보내요. 판단은 더 잘 아는 쪽에 맡기는 거예요.

parseLimitOrDefault 는 "잡는 쪽" 이에요. 여기서는 "변환이 실패하면 기본값 30 을 쓰면 된다" 는 복구 방법을 알아요. 복구할 줄 아니까 try-catch 로 잡아서 30 을 돌려줘요. 화면이 깨지지 않게 안전하게 받쳐주는 거예요.

 같은 예외, 다른 선택

   parseLimit          : 어떻게 복구할지 모름 → 안 잡고 던짐 (위로 전파)
   parseLimitOrDefault : 기본값 30 으로 복구 가능 → 여기서 잡음

main 으로 확인해볼게요.

public static void main(String[] args) {
    HandleOrThrow parser = new HandleOrThrow();

    // 정상 — 숫자 글자는 그대로 변환돼요.
    System.out.println("정상 입력 \"50\" → " + parser.parseLimitOrDefault("50"));

    // 사고 — 숫자가 아닌 글자는 변환에 실패하지만, 잡는 쪽이 기본값 30 으로 복구해요.
    System.out.println("잘못된 입력 \"열개\" → " + parser.parseLimitOrDefault("열개"));
}

"50" 은 그대로 50 으로 변환되고, "열개" 는 변환에 실패하지만 잡는 쪽이 기본값 30 으로 받쳐줘서 프로그램이 멈추지 않아요.

한 가지 더 생각해볼 거리를 남겨둘게요. 만약 잡는 쪽에서 예외를 "다른 예외로 바꿔서" 다시 던지고 싶다면? 그때 원래 원인은 어떻게 보존할까요? 이 이야기는 다음 시간(Day 23) 예외 체이닝에서 다뤄요. 지금은 "잡을지 던질지" 를 판단하는 감각만 챙기면 충분해요.

💡 튜터의 결론

예외를 만나면 "내가 이걸 제대로 복구할 수 있나?" 를 물어보세요. 복구 방법을 알면 그 자리에서 잡고, 모르면 잡지 말고 위로 던져 더 잘 아는 쪽에 맡겨요. 무작정 다 잡는 것도, 무작정 다 던지는 것도 정답이 아니에요. "복구할 수 있는 곳에서 잡는다" 가 핵심이에요.

Step 6: 입력 검증 실전 — 회원 가입 검증기

지금까지 배운 throw 를 실전처럼 써볼게요. 실제 서비스의 회원 가입은 검사할 게 한둘이 아니에요. 이름이 비었는지, 너무 긴지, 나이가 가입 가능한지… 이런 여러 규칙을 throw 로 하나씩 막아봐요.

핵심은 Step 1 에서 본 throw 의 성격이에요. throw 가 실행되면 그 줄에서 메서드가 즉시 멈추니까, 위에서부터 규칙을 하나씩 검사하다가 하나라도 어기면 바로 막혀요. 모든 검사를 통과하면? 아무 일도 안 일어나고 조용히 끝나요. 검증기에서는 "아무 예외도 안 나는 것 = 통과" 예요.

// com/instagram/javabasic/exceptionbasic/SignupValidator.java
public class SignupValidator {

    // 회원 가입 정보를 검사해요. 규칙을 어기면 IllegalArgumentException 으로 막고,
    // 모두 통과하면 아무것도 돌려주지 않고 조용히 끝나요(검사 통과 = 무사 통과).
    public void validate(String username, int age) {
        if (username == null || username.isEmpty()) {
            throw new IllegalArgumentException("사용자 이름을 입력해주세요.");
        }
        if (username.length() > 30) {
            throw new IllegalArgumentException("사용자 이름은 30자까지예요.");
        }
        if (age < 14) {
            throw new IllegalArgumentException("만 14세 이상만 가입할 수 있어요.");
        }
    }
}

규칙이 위에서 아래로 차례대로 검사돼요. 이름이 비면 첫 번째 if 에서 막혀 메서드가 즉시 끝나요(아래 검사는 아예 실행 안 됨). 이름이 너무 길면 두 번째, 나이가 모자라면 세 번째에서 막혀요.

 validate 의 검사 통과 흐름

   이름 비었나?      ──예──▶ throw 💥 (즉시 멈춤)
        │ 아니오
        ▼
   이름 30자 넘나?   ──예──▶ throw 💥 (즉시 멈춤)
        │ 아니오
        ▼
   나이 14세 미만?   ──예──▶ throw 💥 (즉시 멈춤)
        │ 아니오
        ▼
   (끝) ✅ 모든 검사 통과 — 조용히 종료

main 에서 정상 가입과 위반 사례를 확인해볼게요.

public static void main(String[] args) {
    SignupValidator validator = new SignupValidator();

    // 정상 — 모든 규칙을 통과하면 예외 없이 조용히 끝나요.
    validator.validate("minji", 25);
    System.out.println("minji 님 가입 정보가 통과했어요.");

    // 사고 1 — 빈 이름은 첫 검사에서 막혀요.
    try {
        validator.validate("", 25);
    } catch (IllegalArgumentException e) {
        System.out.println("막혔어요: " + e.getMessage());
    }

    // 사고 2 — 나이가 모자라면 마지막 검사에서 막혀요.
    try {
        validator.validate("jaehoon", 13);
    } catch (IllegalArgumentException e) {
        System.out.println("막혔어요: " + e.getMessage());
    }
}

"minji"(25세)는 모든 규칙을 통과해 조용히 끝나고 "통과했어요" 가 찍혀요. 빈 이름은 첫 검사에서, 13세는 마지막 검사에서 막혀 각각 안내 메시지가 나와요.

여기서 살짝 불편한 점이 보일 거예요. 세 가지 다른 사고(빈 이름·긴 이름·어린 나이)를 전부 똑같은 IllegalArgumentException 으로 던지고 있죠? 메시지로만 구분이 되는데, 만약 "이름 문제" 와 "나이 문제" 를 코드에서 다르게 처리하고 싶다면 메시지를 일일이 비교해야 해요. 차라리 이름이 뜻을 분명히 말하는 예외가 있다면 좋을 텐데요. 이 아쉬움이 바로 다음 시간(Day 23) 커스텀 예외로 이어져요.

💡 튜터의 결론

여러 규칙을 검사할 땐 위에서부터 하나씩 throw 로 막으면 돼요. throw 가 실행되면 즉시 멈추니, 어긴 규칙에서 바로 걸러져요. 모두 통과하면 조용히 끝나고요. 검증 메서드는 "예외가 안 나면 통과" 라는 약속으로 동작해요.

Step 7: 종합 — 회원 조회: 던지고 받는 한 흐름

마지막으로 오늘 배운 throw·throws·try-catch 를 한 흐름으로 묶어봐요. Day 20 에서 만든 Repository<Member>(만능 저장소)를 다시 꺼내 쓸 거예요.

기억하시죠? Repository.findById 는 없는 id 를 찾으면 IllegalArgumentException 을 던져요. 저장소가 만든 약속이에요. 이제 그 위에 두 메서드를 얹어요. 하나는 예외를 잡지 않고 전파하는 "던지는 쪽", 하나는 그 예외를 받아 안내 문구로 바꾸는 "받는 쪽" 이에요.

// com/instagram/javabasic/exceptionbasic/MemberLookupFlow.java
public class MemberLookupFlow {

    // 회원을 보관하는 저장소예요. 직접 만들지 않고 밖에서 전달받아 보관해요.
    private final Repository<Member> repo;

    // 생성자 — 쓸 저장소를 외부에서 받아 필드에 담아요.
    public MemberLookupFlow(Repository<Member> repo) {
        this.repo = repo;
    }

    // 던지는 쪽 — 저장소에서 회원을 찾아요. 없으면 저장소가 던진 예외를
    // 여기서 잡지 않고 그대로 호출자에게 전파해요.
    public Member findMember(Long id) {
        return repo.findById(id);
    }

    // 받는 쪽 — findMember 를 try-catch 로 감싸 결과를 안내 문구로 바꿔줘요.
    // 찾으면 환영 인사를, 없으면 전파돼 온 예외를 잡아 안내 문구를 돌려줘요.
    public String greet(Long id) {
        try {
            Member member = findMember(id);
            return member.getUsername() + "님 환영합니다!";
        } catch (IllegalArgumentException e) {
            return "회원을 찾을 수 없어요: " + e.getMessage();
        }
    }
}

흐름이 깔끔하게 세 단계로 나뉘어요.

1. 저장소(findById) — 없는 id 면 예외를 던져요. (Day 20 에서 만든 약속)
2. 던지는 쪽(findMember) — 그 예외를 잡지 않고 그대로 통과시켜요. (전파)
3. 받는 쪽(greet) — try-catch 로 받아 사용자에게 보여줄 안내 문구로 바꿔요.

 없는 id 로 greet 를 부르면

   findById   💥 throw IllegalArgumentException
   findMember (안 잡음, 전파) ──┐
   greet      🧤 catch ◀────────┘ 안내 문구로 바꿔 돌려줌
              "회원을 찾을 수 없어요: ..."

main 으로 전체를 돌려볼게요. 저장소에 회원 두 명을 넣고, 있는 id 와 없는 id 를 둘 다 조회해요.

public static void main(String[] args) {
    // 회원 저장소를 만들어 회원 두 명을 넣어요.
    Repository<Member> repo = new Repository<>();
    repo.save(1L, new Member("minji", 8500, 150, 12, 400));
    repo.save(2L, new Member("jaehoon", 1240, 42, 5, 200));

    MemberLookupFlow flow = new MemberLookupFlow(repo);

    // 있는 id — 환영 인사가 나와요.
    System.out.println(flow.greet(1L));
    System.out.println(flow.greet(2L));

    // 없는 id — 저장소가 던진 예외가 findMember 를 거쳐 greet 까지 전파되고,
    // greet 가 잡아 안내 문구로 바꿔 돌려줘요. 프로그램은 멈추지 않아요.
    System.out.println(flow.greet(99L));
}

id 1번과 2번은 "minji님 환영합니다!", "jaehoon님 환영합니다!" 가 나오고, 없는 99번은 저장소가 던진 예외가 findMember → greet 로 전파돼 "회원을 찾을 수 없어요: id 99 에 해당하는 항목이 없어요." 가 나와요. 던지고(저장소)·전파하고(findMember)·받는(greet) 흐름이 한 바퀴 도는 거예요.

💡 튜터의 결론

던지고·전파하고·받는 세 단계가 한 흐름으로 엮였어요. 저장소가 약속대로 예외를 던지면, 중간 메서드는 전파만 하고, 복구할 줄 아는 곳에서 잡아 안내 문구로 바꿔요. 오늘 배운 throw·throws·try-catch 가 실제 조회 기능 하나에 모두 들어간 거예요. 이게 바로 실무에서 예외를 다루는 기본 골격이에요.

마무리

• Step 1: throw new 예외종류("메시지") 로 내가 직접 예외를 던져요. 그 줄에서 메서드는 즉시 멈추고 예외가 위로 튀어요. Day 20 Repository.findById 도 이렇게 던지고 있었어요.
• Step 2: 예외는 두 종류 — RuntimeException 자손은 unchecked(강제 안 함), 그 외 Exception 자손은 checked(throws 나 try-catch 강제). unchecked 는 "내 실수", checked 는 "바깥 사정".
• Step 3: throws 는 "이 예외를 안 잡고 넘긴다" 는 메서드 표지판. throw(동작, s 없음)와 throws(선언, s 있음)는 한 글자 차이지만 역할이 달라요.
• Step 4: 아무도 안 잡은 예외는 콜스택을 거슬러 올라가요(전파). 끝까지 안 잡으면 프로그램이 멈춰요.
• Step 5: "복구할 수 있으면 잡고, 모르면 던진다." 무작정 다 잡거나 다 던지는 게 아니라, 복구 가능한 곳에서 잡아요.
• Step 6: 여러 규칙은 위에서부터 throw 로 하나씩 막아요. 모두 통과하면 조용히 끝나요.
• Step 7: 던지고(저장소)·전파하고(findMember)·받는(greet) 전체 흐름을 한 기능으로 엮었어요.

다음 시간엔 — 나만의 예외를 만들기

오늘 우리는 검증할 때마다 IllegalArgumentException 을 던졌어요. 그런데 Step 6 에서 느꼈듯, 빈 이름·긴 이름·어린 나이를 전부 같은 예외로 던지니 메시지로만 구분해야 해서 조금 불편했죠. 만약 MemberNotFoundException(회원을 못 찾음) 처럼 이름만 봐도 무슨 사고인지 아는 예외가 있다면 어떨까요?

다음 시간엔 이렇게 나만의 예외 클래스를 직접 만드는 법(커스텀 예외)을 배워요. 그리고 예외를 잡아 다른 예외로 바꿔 던질 때 원래 원인을 보존하는 예외 체이닝, 자원을 자동으로 닫아주는 try-with-resources 도 익혀요. 오늘 던지는 법을 배웠으니, 다음엔 "잘 설계된 예외" 를 만드는 거예요. 수고 많으셨어요!

과제

오늘 배운 throw·throws·예외 처리 전략을 손에 익히는 과제예요. 모두 오늘까지 배운 문법(클래스·상속·인터페이스·Comparable·List/Set/Map·제네릭·예외 처리·향상된 for)만으로 풀 수 있어요. 커스텀 예외 클래스와 try-with-resources 는 다음 시간 주제라 오늘 과제에는 쓰지 않아요. 표준 예외(IllegalArgumentException·IllegalStateException 등)만 직접 던지면 돼요.

과제 1: [기초] 게시물 좋아요 수 검증기

해야 할 일

게시물의 좋아요 수를 검사하는 메서드를 만들어보세요. 좋아요 수는 0 보다 작을 수 없어요(음수면 데이터가 잘못된 거예요). 음수가 들어오면 throw 로 막아요.

요구사항

• int validateLikeCount(int likeCount) 메서드를 만들어요.
• likeCount 가 0 보다 작으면 throw new IllegalArgumentException("좋아요 수는 음수일 수 없어요: " + likeCount) 로 막아요.
• 정상(0 이상)이면 그 값을 그대로 돌려줘요.
• main 에서 정상 값(예: 100)과 음수 값(예: -5)을 둘 다 호출하고, 음수는 try-catch 로 받아 메시지를 출력해요.

힌트

• Step 1 의 validateCaption 구조를 그대로 따라가면 쉬워요. if 로 검사하고 어기면 throw, 통과하면 return.
• 던진 예외는 main 에서 catch (IllegalArgumentException e) 로 받아 e.getMessage() 를 출력하면 돼요.

과제 2: [응용] 던질까 잡을까: 두 메서드로 나누기

해야 할 일

Step 5 의 "던지는 쪽 / 잡는 쪽" 패턴을 직접 만들어보세요. 사용자가 입력한 나이 글자(String)를 숫자로 바꾸는 상황이에요.

요구사항

• int parseAge(String raw) 메서드("던지는 쪽")를 만들어, Integer.parseInt(raw) 로 변환만 해요. 숫자가 아니면 NumberFormatException 이 그대로 전파되게 두고, 잡지 마세요.
• int parseAgeOrDefault(String raw) 메서드("잡는 쪽")를 만들어, parseAge 를 try-catch 로 감싸요. NumberFormatException 이 나면 기본값 0 을 돌려줘요.
• main 에서 정상 입력("20")과 잘못된 입력("스무살")을 둘 다 parseAgeOrDefault 로 호출해 결과를 확인해요.

힌트

• parseAge 에는 try-catch 를 절대 넣지 마세요. "복구 방법을 모르니 그냥 던진다" 가 이 메서드의 역할이에요.
• 복구(기본값 0)는 parseAgeOrDefault 에서만 해요. 같은 예외라도 "어디서 잡느냐" 가 전략이라는 걸 직접 느껴보세요.

과제 3: [심화] 전파 따라가기: 3단 호출 체인

해야 할 일

Step 4 의 콜스택 전파를 직접 만들어보세요. 메서드 3개가 서로를 부르는 체인을 만들고, 가장 깊은 곳에서 던진 예외가 맨 위까지 거슬러 올라오는 걸 확인해요.

요구사항

• 가장 깊은 메서드 String readBio(String bio) 를 만들어, bio 가 null 이거나 빈 문자열이면 throw new IllegalStateException("자기소개가 비어 있어요."), 정상이면 bio 를 돌려줘요.
• 중간 메서드 String buildProfileCard(String bio) 는 try-catch 없이 readBio(bio) 를 호출해 그 결과를 돌려줘요.
• 맨 위 메서드 String renderProfilePage(String bio) 도 try-catch 없이 buildProfileCard(bio) 를 호출해 그 결과를 돌려줘요.
• main 에서 renderProfilePage(null) 을 try-catch 로 감싸 호출하고, 맨 깊은 곳의 예외가 main 까지 전파돼 잡히는지 확인해요.

힌트

• 중간 두 메서드(buildProfileCard·renderProfilePage)에는 try-catch 를 넣지 마세요. 그래야 예외가 통과해서 위로 올라가요.
• IllegalStateException 은 unchecked 라 중간 메서드에 throws 선언도 필요 없어요. 그냥 호출만 하면 예외가 알아서 전파돼요.

생각해볼 주제

오늘 배운 "던지고 전파" 뒤에는 "그래서 예외를 어떻게 던지는 게 좋은가?" 하는 질문이 숨어 있어요. 정답을 외우기보다 곰곰이 생각해보면 도구를 보는 눈이 깊어져요.

1. throw 로 막을 일을 if 로 false 만 돌려주면 안 될까?

Step 6 의 회원 가입 검증기는 규칙을 어기면 throw 로 예외를 던졌어요. 그런데 이렇게 생각할 수도 있어요. "예외까지 던질 것 없이, 그냥 boolean 으로 false 를 돌려주면 안 되나요? 통과하면 true, 아니면 false 로요." 얼핏 더 간단해 보이죠. 하지만 false 만 돌려주면 "무엇이 왜 잘못됐는지" 정보가 사라지고, 부른 쪽이 그 false 를 깜빡 무시하고 다음 코드를 그냥 진행할 수도 있어요. 예외를 던질 때와 false 를 돌려줄 때, 각각 어떤 상황에서 더 안전한지 생각해보세요.

2. 모든 메서드에 throws Exception 을 붙여두면 편하지 않을까?

Step 3 에서 checked 예외를 넘기려면 throws Exception 을 붙여야 했어요. 그런데 매번 어떤 예외를 넘길지 고민하기 귀찮으니, 아예 모든 메서드에 throws Exception 을 기본으로 붙여두면 컴파일 에러도 안 나고 편할 것 같아요. 정말 그럴까요? 메서드 시그니처의 throws 는 "이 메서드를 부르면 이런 예외에 대비해야 해" 라는 약속이기도 해요. 모든 메서드가 throws Exception 이면 그 약속이 어떤 의미를 잃게 될지, 부르는 쪽 입장에서 따져보세요.

3. 예외는 정말 "예외적인" 상황에만 써야 할까?

오늘 우리는 잘못된 입력, 없는 회원처럼 "예상 밖의 사건" 에 예외를 썼어요. 그런데 예외는 편리해서, 평범한 흐름 제어에도 쓰고 싶은 유혹이 생겨요. 예를 들어 반복문을 빠져나오려고 일부러 예외를 던져 잡는다든지요. 이렇게 "정상적인 흐름" 에까지 예외를 쓰면 무엇이 문제일까요? 예외라는 단어 자체가 주는 의미("예외적인 일")와, 코드를 읽는 동료가 받을 혼란을 떠올리며, 예외를 써야 할 상황과 쓰지 말아야 할 상황의 경계를 그어보세요.