Error 404에러 처리와 서버에러 처리

[sgoldenbird]

🧭 404 에러 처리

✅ 라우터 경로가 잘못된 경우 (예: /abcxyz)

• 정의되지 않은 경로로 진입 시
• path: '*', element: <NotFoundPage /> 로 처리
• <NotFoundPage>는 전체 404 이미지, 메인으로 돌아가는 버튼 포함

{
  path: '*',
  lazy: async () => {
    const { NotFoundPage } = await import('@/pages/error');
    return { Component: NotFoundPage };
  },
}

---

✅ 올바른 경로지만 데이터가 없는 경우 (예: /list?id=999)

• 라우트는 맞지만, 해당 ID에 해당하는 데이터가 없을 경우
• throw new Response(..., { status: 404 }) 로 명시적 에러 발생
• <ApiErrorBoundary>에서 잡아서 처리하고, 사용자에게 메시지 보여줌
• 예를 들어 요청은 정상적으로 됐고 서버가 200 OK로 응답했지만 idols.length === 0인 경우
  → 즉 "페이지는 존재하지만 컨텐츠 없음", 사용자 입장에서 404 느낌이 나는 상황
  → 이럴 땐 404로 처리하는 게 UX적으로 자연스러움

loader: async () => {
  const data = await fetch('/api/item');
  if (!data) {
    throw new Response('데이터 없음', { status: 404 });
  }
  return data;
}

---

• 왜 NotFoundPage로 처리하지 않나?
  • NotFoundPage는 **"페이지가 존재하지 않는 경우"**에만 사용
  • 데이터 없음은 **"페이지는 있지만 내부 컨텐츠 없음"**이므로 UX 메시지 처리

---

📌 404 처리 요약

상황	보여줄 화면	처리 위치
잘못된 URL 접근	<NotFoundPage>	path: "*"
올바른 경로 + 데이터 없음	"데이터가 없습니다" 등 메시지	<ApiErrorBoundary>
쿼리 없음, 잘못된 조건	"검색어를 입력해주세요" 등	페이지 내부에서 처리

---

🔥 서버 에러 처리 (HTTP 5xx)

✅ 서버 에러 상태코드

상태코드	의미
500	Internal Server Error
502	Bad Gateway
503	Service Unavailable

---

✅ 페이지 내 API 요청 중 서버 에러

• 위와 같이 명시적으로 throw new Response(..., { status: 500 }) 하면
• 해당 라우트의 errorElement인 <ApiErrorBoundary>가 감지하여 fallback UI 제공

---

✅ 전역 치명적 에러

• <GlobalErrorBoundary>에서 최종 fallback 처리
• 루트 라우트(/)에 errorElement로 지정

---

✅ 의도적으로 서버 에러 테스트할 경우

loader: async () => {
  throw new Response("테스트 서버 에러", { status: 500 });
}

• 테스트 전용 페이지에서 사용 test-error
• 이 경우 루트의 <GlobalErrorBoundary>에서 fallback

---

📌 서버 에러 처리 요약

상황	처리 주체	보여줄 UI
/list에서 API 서버 오류	<ApiErrorBoundary>	에러 메시지 + 다시 시도 버튼
전역적으로 잡히지 않은 예외	<GlobalErrorBoundary>	<ServerErrorPage>
테스트용 에러 발생	<GlobalErrorBoundary>	<ServerErrorPage>

---