🚨 REST API 예외처리 정리

✅ 어떤 기능을 만드는 것인가?

• 데이터만 주고받는 REST API에서 발생하는 다양한 에러(입력 오류, 타입 불일치, 서버 내부 오류)를 일관된 포맷과 상태코드로 응답
• 타임리프(뷰 렌더링) 환경의 error.html 대신, JSON/문자 응답 + HTTP Status로 처리

---

👉 왜 이걸 배워야 하지?

• 프론트는 HTML이 아니라 상태코드 + 메시지를 보고 분기한다.
• 예외를 중앙집중 처리하면 중복 코드를 제거하고, 운영 이슈를 빠르게 파악할 수 있다.
• 면접/실무 단골: ResponseEntity, @ExceptionHandler, @ControllerAdvice, HTTP status 설계

---

📚 개념 정리

개념	설명
try { } catch	블록 내부에서 예외가 나면 catch로 분기하여 복구/응답 처리
throws Exception	메서드가 예외를 던질 수 있음을 선언(로컬 처리 없을 때 경고용)
ResponseEntity<T>	상태코드 + 헤더 + 바디를 함께 제어하는 응답 컨테이너
@ExceptionHandler	해당 컨트롤러 클래스 범위에서 발생한 예외를 한 곳에서 처리
@ControllerAdvice	전역(모든 컨트롤러) 예외 처리. 스코프를 패키지/어노테이션 기준으로 제한 가능
HTTP Status	2xx 성공, 4xx 클라이언트 오류, 5xx 서버 오류 등 응답 의미 체계

타임리프 사용 시 서버 에러 → templates/error.html로 자동 이동(뷰 응답).
REST API는 뷰를 열지 않으므로 상태코드/문자(JSON)로 응답해야 함.

---

⚙️ 구현 흐름 및 코드 (실습 순서)

1) 가장 단순한 로컬 처리: try / catch

@GetMapping("/detail/{id}")
@ResponseBody
public String detail() {
    try {
        // 에러 가능 코드
        throw new Exception("이런저런에러");
    } catch (Exception e) {
        System.out.println(e.getMessage()); // 서버 로그
        return "에러남 ㅅㄱ";                // 단순 문자열 응답
    }
}

• 장점: 빠르고 지역적
• 단점: 중복/난립. 상태코드 제어 불가(문자만 응답)

---

2) 상태코드까지 명시: ResponseEntity

@GetMapping("/detail/{id}")
public ResponseEntity<String> detail() {
    try {
        // ...
        throw new Exception("이런저런에러");
    } catch (Exception e) {
        return ResponseEntity
                .status(400)                     // HttpStatus.BAD_REQUEST 도 가능
                .body("잘못된 요청: " + e.getMessage());
    }
}

• 프론트가 status로 분기 가능 → 협업 친화
• 정상 응답도 ResponseEntity.ok(body)처럼 통일해두면 좋음

자주 쓰는 상태코드: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error

---

3) 컨트롤러 단위 공통 처리: @ExceptionHandler

@Controller
public class ItemController {

    @GetMapping("/items/{id}")
    public ResponseEntity<String> get(@PathVariable Long id) {
        if (id < 0) throw new IllegalArgumentException("음수 ID 불가");
        return ResponseEntity.ok("OK");
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handle(Exception e) {
        return ResponseEntity.status(400).body("컨트롤러 공통 에러: " + e.getMessage());
    }
}

• 같은 컨트롤러 내 API들의 예외를 한 번에 처리
• 더 구체적인 예외 타입을 여러 개 메서드로 나눠서 매핑 가능

---

4) 전역 공통 처리: @ControllerAdvice

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> handleBadRequest(IllegalArgumentException e) {
        return ResponseEntity.status(400).body("잘못된 요청: " + e.getMessage());
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGeneral(Exception e) {
        return ResponseEntity.status(500).body("서버 오류: 잠시 후 다시 시도해주세요");
    }
}

• 모든 컨트롤러에 적용되는 전역 예외 처리기
• 우선순위: 로컬 @ExceptionHandler > 전역 @ControllerAdvice

실무 팁

• 공통 에러 응답 DTO(예: {code, message, path, timestamp})를 만들어 형식 통일
• 로깅은 Slf4j/Logback으로 남기고, 민감정보 응답 금지

---

5) 타입 불일치 등 특정 예외 핸들링

import org.springframework.web.method.annotation.MethodArgumentTypeMismatchException;

@ControllerAdvice
public class SpecificHandler {
    @ExceptionHandler(MethodArgumentTypeMismatchException.class)
    public ResponseEntity<String> mismatch(MethodArgumentTypeMismatchException e) {
        return ResponseEntity.status(400).body("파라미터 타입 오류");
    }
}

• 예: /detail/abc → Long 변환 실패 시 매핑되는 예외

---

💡 이런 곳에 활용할 수 있어요

• REST 기반 상품/게시글/회원 API 전반
• 유효성 검증 실패, 권한 부족, 리소스 없음(404), 서버 장애
• 공통 에러 포맷 제공으로 프론트/앱/외부 파트너와 안정적 통신

---

✍️ 개인 정리 및 회고

• 타임리프 환경의 error.html은 뷰 응답일 뿐, REST에는 맞지 않는다.
• 응답은 상태코드가 언어다. 2xx/4xx/5xx를 정확히 나눠라.
• 전역 예외 처리와 공통 응답 포맷을 도입하니 코드가 단정해진다.

---

🔑 오늘 배운 핵심 3줄 요약

1. REST API 예외는 뷰 대신 ResponseEntity(상태코드+메시지) 로 응답
2. 공통 처리는 @ExceptionHandler → @ControllerAdvice 순으로 확장
3. 상태코드 규칙(200/201/400/401/403/404/500)을 팀 표준으로 고정

---