Error Boundary는 어떤 오류를 잡고 어떤 오류는 잡지 못하나요?
답변 포인트
렌더링 오류와 이벤트/비동기 오류의 차이를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.
정답 및 해설
빠른 요약
Error Boundary는 하위 트리의 렌더링과 생명주기 오류를 잡아 fallback UI를 보여줄 수 있습니다. 이벤트 핸들러, 비동기 콜백, 자기 자신의 오류는 별도 처리가 필요합니다.
Error Boundary는 하위 트리의 렌더링과 생명주기 오류를 잡아 fallback UI를 보여줄 수 있습니다. 이벤트 핸들러, 비동기 콜백, 자기 자신의 오류는 별도 처리가 필요합니다.
핵심 개념
핵심 기준은 렌더링 오류와 이벤트/비동기 오류의 차이입니다. 이 개념은 단순한 용어가 아니라, 실제 코드나 시스템에서 반복적으로 생기는 문제를 다루기 위해 등장했습니다.
React에서는 상태 변화가 렌더링으로 이어지는 흐름을 예측 가능하게 만드는 것이 중요합니다. 컴포넌트 경계와 렌더링 비용을 이해하면 더 부드러운 UI를 만들 수 있습니다.
동작 흐름
- 먼저 어떤 문제가 있는지 확인합니다.
- 이 개념이 그 문제를 어떤 기준으로 나누거나 해결하는지 봅니다.
- 실제 코드에서는 입력, 상태, 실행 순서, 비용이 어떻게 바뀌는지 확인합니다.
- 마지막으로 한계와 부작용을 함께 점검합니다.
실제 예시
class ErrorBoundary extends React.Component {
state = { hasError: false };
static getDerivedStateFromError() {
return { hasError: true };
}
render() {
return this.state.hasError ? <Fallback /> : this.props.children;
}
}Error Boundary는 렌더링 중 오류를 잡지만 이벤트 핸들러나 비동기 오류는 별도 처리가 필요합니다.
실무에서 주의할 점
- 상태를 너무 위로 올리면 불필요한 렌더링 범위가 커집니다.
- memoization은 병목이 확인된 곳에 쓰는 편이 좋습니다.
- 사용자 입력, 로딩, 에러 상태를 함께 설계해야 실제 화면이 안정적입니다.
함께 연결해서 보면 좋은 키워드
React, ErrorBoundary, 예외처리, UX
정리
한 줄로 정리하면, Error Boundary는 하위 트리의 렌더링과 생명주기 오류를 잡아 fallback UI를 보여줄 수 있습니다. 이벤트 핸들러, 비동기 콜백, 자기 자신의 오류는 별도 처리가 필요합니다. 실무에서는 개념을 적용하는 조건과 적용하지 않았을 때 생기는 문제까지 함께 이해하는 것이 중요합니다.
Error Boundary의 범위
Error Boundary는 하위 컴포넌트의 렌더링, 생명주기, constructor에서 발생한 오류를 잡아 fallback UI로 전환합니다. 하지만 이벤트 핸들러와 비동기 오류는 자동으로 잡지 못합니다.
function SaveButton() {
async function handleClick() {
try {
await save();
} catch (error) {
setError(error); // 이벤트/비동기는 직접 처리
}
}
return <button onClick={handleClick}>저장</button>;
}배치 전략
- 앱 최상단: 완전한 흰 화면 방지
- 라우트 단위: 특정 페이지 오류 격리
- 위젯 단위: 외부 위젯/차트 오류가 전체를 깨지 않게 함
함께 해야 할 일
fallback만 보여주면 원인 파악이 어렵습니다. componentDidCatch 또는 라이브러리의 onError 콜백에서 에러, component stack, 사용자 행동, release version을 로깅해야 합니다.