Error Boundary가 Event Handler 에러를 잡지 못하는 이유

처음 Error Boundary를 사용했을 때 헷갈렸던 부분이 있었다.

분명 Error Boundary를 만들었는데,
버튼 클릭 중 발생한 에러는 잡히지 않았다.

예를 들어

const handleClick = () => {
  throw new Error('Exception');
};

<button onClick={handleClick}>
  Click me
</button>

처음에는

"에러가 발생했는데 왜 Error Boundary가 안 잡지?"

라고 생각했다.

문제는 Error Boundary가 “모든 에러”를 잡는 기능이 아니라는 점이었다.

React Error Boundary는 React 렌더링 과정에서 발생한 에러만 처리한다.

render
lifecycle
render phase update

에서 발생한 에러는 잡을 수 있다.

반면

event handler
async callback
setTimeout
Promise callback

같은 React 렌더링 흐름 밖의 에러는 잡지 못한다.

왜 Event Handler 에러는 못 잡을까

이 차이를 이해하려면 React가 Error Boundary를 언제 사용하는지 봐야 한다.

Error Boundary는 React reconciliation/rendering 과정에서 동작한다.

예를 들어

function Profile() {
  throw new Error('Render Error');
}

이 에러는 React가 컴포넌트를 렌더링하는 중에 발생한다.

React render 시작
→ 컴포넌트 실행
→ 에러 발생
→ Error Boundary fallback 렌더링

흐름이 된다.

반면 event handler는 다르다.

const handleClick = () => {
  throw new Error('Exception');
};

이 코드는 이미 렌더링이 끝난 뒤, 브라우저 이벤트 시스템 안에서 실행된다.

흐름은 이렇다.

렌더링 완료
→ 사용자가 클릭
→ 브라우저 이벤트 실행
→ 에러 발생

즉 React 렌더링 흐름 밖이다. 그래서 Error Boundary가 잡지 못한다.

처음에는 try/catch만 사용했다

초기에는 대부분 이렇게 처리했다.

const handleClick = async () => {
  try {
    await savePost();
  } catch (error) {
    toast.error('저장 실패');
  }
};

간단한 UI에서는 충분하다.

문제는 에러 상태를 페이지 레벨에서 처리하고 싶을 때였다.

예를 들어

특정 영역 전체 fallback
에러 UI 공통 처리
route-level error.tsx
reset boundary

와 연결하려고 하면 단순 try/catch만으로는 한계가 생긴다.

이벤트 에러를 다시 “렌더링 과정”으로 가져온다?

이벤트에서 에러 발생
state에 저장
다음 렌더링에서 throw
Error Boundary가 처리

흐름으로 바꾼다.

state를 이용한 방식

'use client';

import { useState } from 'react';

export function Button() {
  const [error, setError] = useState<Error | null>(null);

  const handleClick = () => {
    try {
      throw new Error('Exception');
    } catch (reason) {
      setError(reason as Error);
    }
  };

  if (error) {
    throw error;
  }

  return <button onClick={handleClick}>Click me</button>;
}

여기서 핵심은 이 부분이다.

if (error) {
  throw error;
}

이제 에러는 event handler 안에서 끝나지 않는다.

흐름이 바뀐다.

클릭 이벤트
→ 에러 발생
→ state 저장
→ React 재렌더링
→ render 중 throw
→ Error Boundary가 처리

즉 “에러를 렌더링 단계로 다시 던진다.” 가 핵심이다.

이 방식의 장점

약간 억지스럽다.

근데 실제로는

fallback UI 통합
route-level error 처리
reset boundary 연동

측면에서 꽤 유용했다.

특히 Next.js App Router에서는

error.tsx

와 자연스럽게 연결할 수 있다.

문제점

반대로 단점도 있다. 에러를 state에 저장하고 다시 throw하는 방식은

"에러를 렌더링용 state로 변환"

하는 구조다.

boilerplate 증가
같은 패턴 반복
try/catch + state + throw 필요

문제가 있다.

그래서 React는 더 자연스러운 방법을 제공한다.

startTransition 사용

'use client';

import { useTransition } from 'react';

export function Button() {
  const [pending, startTransition] = useTransition();

  const handleClick = () =>
    startTransition(() => {
      throw new Error('Exception');
    });

  return <button onClick={handleClick}>Click me</button>;
}

왜 startTransition은 가능한가

핵심은

startTransition 내부 작업은
React transition update 흐름 안에서 처리된다.

는 점이다. 일반 이벤트 핸들러

브라우저 이벤트 실행
→ React render와 분리
→ Error Boundary 못 잡음

startTransition

클릭 이벤트
→ React transition update 예약
→ React render pipeline 안에서 실행
→ Error Boundary 가능

즉 에러 발생 위치보다 중요한 건 “React 렌더링 흐름 안인가” 다.

startTransition이 원래 하는 일

startTransition은 원래 에러 처리를 위한 API가 아니다.

원래 목적은

우선순위 낮은 업데이트 처리

다.

예를 들어

검색 필터링
탭 전환
리스트 렌더링

같은 무거운 업데이트를 transition으로 처리해서 UI blocking을 줄인다.

startTransition(() => {
  setSearchQuery(value);
});

근데 이 업데이트가 React render pipeline 안에서 실행되기 때문에,
에러도 Error Boundary가 잡을 수 있는 것이다.

즉 transition이라서”가 아니라,
“React render update로 처리되기 때문” 이다.

하지만 모든 에러를 Error Boundary에 던지진 않는다

이게 중요하다.

처음엔

"모든 에러를 Boundary로 처리해야 하나?"

라고 생각했다.

근데 실제로는 그렇지 않았다.

예를 들어

폼 validation 실패
네트워크 timeout
사용자 입력 오류

이런 건 일반 UI 상태로 처리하는 편이 자연스럽다.

반면 Error Boundary는 보통

복구 불가능한 UI 오류
컴포넌트 crash
예상 못한 rendering 문제

를 처리하는 데 더 가깝다.

내 생각

처음에는 Error Boundary가 모든 에러를 잡는다고 생각했다.

하지만 실제로는

React 렌더링 과정 안에서 발생한 에러만 처리한다.

즉 일반 event handler 에러는

브라우저 이벤트 시스템 안에서 실행되기 때문에
Error Boundary가 잡지 못한다.

이를 해결하려면

state에 저장 후 render에서 throw하거나
startTransition 안에서 React update 흐름으로 넘겨야 한다.

핵심은

에러를 React render pipeline 안으로 가져오는 것

이다.

그리고 실무에서는 모든 에러를 Boundary로 처리하기보다

복구 가능한 에러 → UI 상태 처리
UI 자체가 깨지는 에러 → Error Boundary 처리

처럼 역할을 나누는 게 더 중요했다.

Error Boundary와 StartTransition