React 비동기 에러 핸들링

 

에러 핸들링의 목표는 두 가지다

에러 처리는 단순히 try / catch를 쓰는 문제가 아니다.
목표는 명확하다.

1. 개발자가 문제를 인지할 수 있는가
   • 어디서
   • 왜
   • 어떤 에러가 났는지
2. 사용자에게 비정상 상황을 적절히 보여주는가
   • 멈췄다는 사실을 알려주는지
   • 다시 시도할 수 있는지
   • 최소한 망가진 화면은 아닌지

 

---

에러 처리의 기초: throw는 어디까지 전파될까?

function foo(s) {
  console.log("foo start");
  if (typeof s !== 'string') throw '에러';
  console.log("foo end");
}

function bar() {
  console.log("bar start"); 
  foo(1);
  console.log("bar end");
}

function baz() {
  console.log("baz start");
  bar();
  console.log("baz end");
}

baz();

 

이 코드를 실행하면 어디까지 출력될까?

• foo end는 실행되지 않는다
• bar end, baz end도 실행되지 않는다

에러는 가장 가까운 catch를 만날 때까지 콜스택을 타고 올라간다.

---

Error 객체로 던져야 하는 이유

throw new Error("에러");

 

문자열 대신 Error를 던지면:

• stack trace가 생기고
• 어디서 터졌는지 추적이 가능해진다

디버깅 관점에서는 선택이 아니라 기본값에 가깝다.

---

에러 처리는 어디서 해야 할까?

모든 함수가 에러를 잡아야 할까?
결론부터 말하면 아니다.

순수 함수는 굳이 에러를 잡지 않는다

• 입력 → 출력이 명확하고
• 부수 효과가 없는 함수는
• 예상 가능한 범위에서만 동작한다

오히려 과도한 방어 로직이 코드를 복잡하게 만든다.

---

사이드 이펙트가 있는 곳에서 잡는다

• 네트워크 요청
• 파일 시스템 접근
• 외부 API 호출

예측 불가능한 지점에서 에러 핸들링이 필요하다.

그리고 중요한 원칙 하나:

호출되는 함수는 에러를 던지고,
호출하는 쪽에서 처리한다.

 

 

그래야 서비스 맥락에 맞는 대응이 가능하다.

 

동기와 비동기 에러는 다르게 동작한다

동기 에러는 익숙하다

try {
  JSON.parse("{");
} catch (e) {
  console.log(e.message);
}

문제 없다. 바로 잡힌다.

---

비동기에서는 상황이 달라진다

try {
  setTimeout(() => {
    JSON.parse("{");
  }, 1000);
} catch (e) {
  console.log(e.message);
}

이 코드는 에러를 잡지 못한다.

이유는 단순하다.

• setTimeout은 콜백을 등록만 하고
• 현재 실행 컨텍스트는 이미 종료되었기 때문이다

try/catch는 같은 실행 흐름 안에서만 동작한다.

---

async / await도 만능은 아니다

(async function() {
  try {
    setTimeout(() => {
      throw 'error';
    }, 1000);
  } catch (e) {
    console.log(e);
  }
})();

여전히 잡히지 않는다.
async는 Promise를 await할 때만 의미가 있다.

---

비동기 에러를 잡는 올바른 방법

Promise reject + await

(async function() {
  try {
    await new Promise((_, reject) =>
      setTimeout(() => reject("error"), 1000)
    );
  } catch (e) {
    console.log(e);
  }
})();

이제 잡힌다.

• reject → await → catch
• 하나의 흐름으로 이어졌기 때문이다

---

또는 Promise 체이닝

new Promise((_, reject) =>
  setTimeout(() => reject("error"), 1000)
)
.catch(e => {
  console.log(e);
});

---

fetch 사용 시 흔한 오해

try {
  await fetch("잘못된 주소");
} catch (e) {
  console.log(e);
}

이 코드는 네트워크 에러일 때만 catch에 들어온다.

• 404
• 500

이건 에러가 아니다.
fetch는 Response 객체를 정상적으로 반환한다.

---

HTTP 에러는 직접 처리해야 한다

const res = await fetch(url);

if (!res.ok) {
  throw new Error(`HTTP 오류 발생: ${res.status}`);
}

이제야 비로소:

• 네트워크 에러 → catch
• HTTP 에러 → 우리가 만든 에러 → catch

---

서비스 레이어에서 에러를 처리하자

async function getData() {
  const res = await fetch(url);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

async function service() {
  try {
    const data = await getData();
    renderPage(data);
  } catch (e) {
    handleServiceError(e);
  }
}

• API 함수는 판단하지 않는다
• 서비스 코드가 “이 에러를 어떻게 보여줄지” 결정한다

이 구조가 유지보수에 가장 유리하다.

---

정리: 비동기 에러는 조용히 터진다

비동기 에러의 가장 무서운 점은 이거다.

터졌다는 사실조차 모를 수 있다.

그래서 필요한 건

• 어디서 에러를 던질지 정하는 기준
• 어디서 잡을지에 대한 합의
• “이 상황을 테스트해봤는가?”라는 질문

이다.