[React] React 에러 구조 설계: throw만으로 선언적 에러 핸들링 하기
"이 에러가 통계 섹션 문제인가요, 차트 섹션 문제인가요?"
모든 에러가 단순히 Error 인스턴스라면, ErrorBoundary에서 이를 구분하여 부분적으로 처리하기가 어렵습니다. 이 문제를 해결하기
위해 에러 클래스를 계층적으로 설계하고, throw를 활용해 선언적으로 처리하는 방법을 소개합니다.
🏗️ 에러도 설계가 필요하다
-
계층적 클래스 설계: Error -> ApiError -> StatsError와 같이 에러에도 족보를 만들어 관리합니다.
-
Throw vs Return: 왜 return error 패턴보다 throw가 선언적 처리에 적합한지, 그리고 React Query + Suspense와 어떻게 시너지를
내는지 알아봅니다. -
선택적 에러 캐치: instanceof를 활용해 특정 섹션의 에러만 담당하고, 나머지는 상위로 전파하는 똑똑한 ErrorBoundary를
구현합니다.🎯 결과: 견고한 대시보드
이 설계를 통해 통계 섹션이 터져도 차트는 정상적으로 동작하는, 실패 격리가 완벽한 대시보드를 구축할 수 있습니다. "누가 이
에러를 처리해야 하지?"라는 고민을 코드 구조로 해결해보세요.👉 [전체 읽기: React 에러 구조 설계: throw만으로 선언적 에러 핸들링 하기]
🔗 https://blog.sangwook.dev/posts/react-error-deign (https://blog.sangwook.dev/posts/react-error-deign)
18개의 댓글
좋은 글 감사합니다.
궁금한게, 에러 바운더리는 렌더링 라이프 사이클중에 에러를 잡아서 처리하는걸로 알고있는데, 저렇게 비동기인 경우도 throw 하면 잘 바운더리에 잡히나요??
그리고, 각 컴포넌트가 마다 API 에러를 세세하게 제어할려면 보일러플레이트 코드가 좀 늘어날것같은 생각도 조금 드네요.
오랜만이라 조금 헷갈려서 글 남겨봅니다. 감사합니다.
정말 유익한 글 감사합니다! 🙌
ErrorBoundary를 계층적으로 설계하는 방식이 인상 깊었습니다. 특히 StatsError, ChartError 등 도메인별로 구분해서 처리하는 구조는 유지보수성과 디버깅 측면에서 큰 도움이 될 것 같아요.
혹시 이 구조를 모바일 앱에서도 적용해보신 경험이 있으신가요? React Native나 Flutter에서도 비슷한 패턴이 가능할지 궁금합니다.
앞으로도 좋은 글 기대하겠습니다!
좋은글 잘읽구 가용!!
어떻게 보면 가볍게 에러를 던져서 처리하여야 한다고 생각하기 쉽지만,
시스템적으로 에러를 핸들링 하고, 나아가서 유관부서와의 에러 파악을 원활하게 하기위해서
외부 SaaS(amplitude, hotjar, sentry 등) 을 사용할 경우에 계층간 분리된 에러를 던질때
보다 명확하게 어떤 에러인지 명기할 수 있어서 좋을 것 같다는 생각을 하게 되었어용!!
역시 채고입니다!!
좋은글 잘 읽었습니다! 다양한 디자인 패턴이나 패러다임들이 녹아든 코드는 항상 명시적이고 유지보수성이 좋아보이는것 같습니다.
고생 많으셨습니다!!
저에게 너무 도움이 되는 글이었습니다. Sentry로 에러를 트래킹하고 있는데, 단순하게 Network Error로만 기록돼서 항상 불편했거든요.. 적어주신 전략이 도움이 될 것 같습니다!
글 잘 읽었습니다! 전에 보고 실무 프로젝트에 바로 적용해봤는데, Sentry랑 연동해서 에러 분기도 훨씬 깔끔하게 됐네요 좋은 글 덕분에 많이 배우고 있습니다.
진짜 실무에서 바로 써먹을 수 있는 구조네요. 단순히 “에러를 잘 잡자”가 아니라, “에러의 구조가 곧 ErrorBoundary 전략이 된다”라는 문장이 너무 와닿았습니다.