Error Handling

Runtime Error Case

• API 서버로 일시적으로 문제가 발생한다면 스크립트 에러로 인해 페이지 표시가 안되는 문제 발생

• try & catch 로 감싸도 안전하지 않다.

  • request abort 시 발생되는 error는 AbortError , DOMException이므로 cause 속성이 없다.

  • DOMException error는 일반적인 타입 에러가 아니기 때문에 에러가 일어난 속성(error.cause)이 없어 스크립트 에러로 인해 페이지 표시가 안됨

• JSON.stringify()를 사용할 때 data가 Serializable 하지 않은 경우 (오브젝트가 순환참조가 되는 경우) 타입에러 발생으로 페이지 표시 안됨

제어할 수 없는 에러

• 에러는 상황에 따라 각각 다르게 발생하며 모든 케이스를 완전히 제어하는 것은 어렵다.

• 제어할수 없는 부분에서 UI Blocking을 발생시키는것이 문제

• 제어할 수 없는 부분에서 에러가 발생한 경우, 해당 부분을 감싸 에러가 전파되어 페이지가 중단되는 것을 방지하는 것이 중요

Error Boundary

• UI 일부분의 스크립트 에러가 전체 애플리케이션을 중단해서는 안된다.

• 애플리케이션 전체가 중단되는것을 방지하기 위해 React v16에서 Error Boundary라는 새로운 개념이 도입됨

• React Component tree 하위 내부에 자바스크립트 error를 catch하는 컴포넌트

• 문제가 발생한 부분에 대해 falback UI를 제공한다.

특징

• ErrorBoundary 자식 컴포넌트에서 에러가 발생된 경우 가장 인접한 상위 ErrorBoundary에 제공된 Fallback UI를 렌더링

• ErrorBoundary는 componentDidCatch 라이프사이클 메서드를 사용하여 에러를 처리한다.

  • 해당 메소드는 Class Component에서만 사용이 가능하기 때문에 ErrorBoundary 컴포넌트는 Class로 만들어진다.

• ErrorBoundary를 구현할 때 오류에 대한 응답으로 상태를 업데이트하고 사용자에게 오류 메시지를 표시할 수 있는 Static getDerivedStateFromError, componentDidCatch method 이 구현되어야 한다.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state =  { hasError: false }
  }
  
  // 하위 컴포넌트에서 에러가 발생된 경우 호출됨
  static getDerivedStateFromError(error) {
    // fallback UI를 보여주기 위해 에러 상태를 업데이트 
    return { hasError: true }
  }
  // 에러가 발생된 경우 실행되는 라이프사이클 메소드
  componentDidCatch(error, info) {
    /*
     * Example: componentStack
     *   in ComponentThatThrow (created by App)
     *.  in ErrorBoundray (created by App)
     *.  in div
     *.  in App
    */
     logErrorToMyService(error, info.componentStack);
  }
  
  if (this.state.hasError){
    // render fallback UI 
    return this.props.fallback
  }
  
  return this.props.children
}

• getDerivedStateFromError()

  • error를 매개변수로 갱신될 state를 반환한다.

  • render step에서 호출 (VDOM이 생성되고 이전 VDOM과 비교하는 단계에서 호출됨)

  • VDOM 구성이 깨지면 안되기 때문에 내부에서 사이드이펙트가 발생 가능한 작업을 해선 안됨

  • fallback UI를 렌더링할지 여부를 결정하는 작업으로서 에러 상태를 업데이트하는 코드만 작성

• componentDidCatch()

  • commit step에서 호출 (VDOM 변경사항을 실제 DOM에 적용하는 단계에서 호출됨)

  • 사이드이펙트가 발생해도 무관

  • 에러 정보를 남길 때 사용한다. (에러 로깅)

  • error -> 에러에 대한 정보

  • info -> 어떤 컴포넌트가 에러를 발생시켰는지에 대한 정보 (componentStack)

ErrorBoundary가 다루지 않는 Error

• Async 동작들 (Event Handler, setTimeout, rAF)

  • 사용자 인터렉션 또는 특정 이벤트로 렌더된 이후에 발생되기 때문에 ErrorBoundary가 catch하지 못한다.

  • 즉, 렌더링 도중에 일어난 Error만 catch 가능

  • unhandledrejection 이벤트를 통해 하위 컴포넌트의 비동기 에러를 상위 컴포넌트에서 잡아낼 수 있다.

    • promise.reject가 발생하면 이벤트 발생됨

• ServerSide Rendering

• ErrorBoundary 내부 에러

• try-catch로 처리된 에러

unhandledrejection event

  useEffect(() => {
    window.addEventListener('unhandledrejection', callback);
    return () => {
      window.removeEventListener('unhandledrejection', callback);
    }
  }, []);

react-Error-Boundary

직접 ErrorBoundary를 제작하지 않고 상용화된 라이브러리를 사용

"use client"

import { ErrorBoundary } from 'react-error-boundray';

<ErrorBoundray fallback={<div>Error 발생< /div>}>
  <Component>
</ErrorBoundray>

• fallbackRender() -> props으로 에러에 따른 fallback UI 구성 가능

const fallbackRender = ({ error, resetErrorBoundary }) => {
  // resetErrorBoundary()를 호출하면 에러바운더리 상태를 초기화시키고, 리렌더링
  return (
    <div role='alert'>
      <p>{error.message}</p> 
    </div>
  )
}

<ErrorBoundray 
  fallbackRender={fallbackRender}
  onReset={(details) => {
    // 에러가 다시 발생되지 않기 위해 상태를 초기화시키는 코드 작성
  }}>
  <Component>
</ErrorBoundray>

• useErrorBoundary() hook -

  • 비동기 코드 실행 이후의 발생하는 에러를 대응하기 위한 showBoundary() 를 제공

  • fallback 컴포넌트 내에서 리렌더링을 발생시키기 위한 resetBoundary()를 제공

  • withErrorBoundary() HOC 컴포넌트 제공

import { useErrorBoundary } from 'react-error-boundary'
//...
const { showBoundray } = useErrorBoundary();

useEffect(() => {
  somethingFetch().then().catch(error => showBoundary(error));
}, [])

import { useErrorBoundary } from 'react-error-boundary'

const ErrorFallback = ({ error }) => {
  const { resetBoundary } = useErrorBoundary();
  
  return (
    <div role='alert'>
      <p>{error.message}</p> 
      <button type="button" onClick={resetBoundary}>Try Again</button>
    </div>
  )
}

import { withErrorBoundary } from 'react-error-boundary'

const ComponentWithErrorBoundary = withErrorBoundary(Component, {
  fallback: <div>Error occur</div>,
  onError: (error, info) {}
})

Sentry

코드 관련 문제를 식별하고 수정하는데 도움을 주는 소프트웨어 모니터링 도구

• 런타임 단계의 에러를 수집

• 에러가 발생한 환경에 로그를 직접 확인하는 것은 불가능하고 에러환경의 재현이 불가능하기 때문에 에러를 수집하는것이 중요하다.

• 클라이언트 에러를 수집하여 슬랙을 연동하여 알림 제공

• 소스코드 컨텍스트와 더불어 Stack trace 제공

• Commit 정보 및 Stack trace 기반으로 의심스러운 commit 및 할당자 제안

Sentry 기능

Stack trace

• 제공된 SourceMap 기반 Stack trece로 에러 환경 파악 가능

• 여러 에러를 그룹화하여 하나의 이슈로 정의

• 이벤트가 발생한 코드가 어디에서 에러를 발생 시켰는지 확인 가능

Breadcrumb

• Error Event 발생까지의 기록과 타임라인 제공

• HTTP Request, Console.log, Server log, DOM Event 등이 포함된다.

• 어떤 동작들로 사용자가 에러가 발생했는지 이유를 명확하게 파악하고 해당 컨텍스를 이해함으로써 에러를 재현하기 용이해진다.

Session Replay

• 사용자 세션을 비디오처럼 재현

• 오류/성능 문제 발생 전/후 상황 파악

• 문제의 대한 심층적인 디버깅, 문제를 재현하고 더 빠르게 해결 가능

• UI 이슈의 경우 제공

녹화 시작 트리거

• replay.start() 수동 호출

• 세션이 replaySessionSampleRate에 의해 녹화여부 결정

녹화 종료 트리거

• replay.stop() 수동 호출

• 사용자 비활성 상태, 최대 시간에 도달 (기본 60분)

Alert

• 코드의 문제/ 사용자에게 미치는 영향에 대한 실시간적인 가시성 제공

• 지정한 규칙에 의해 발생되는 alert

• alert 목록 필터링, alert에 대한 비활성화/mute 기능, notification 제공

설치

npx @sentry/wizard@latest -i nextjs

부가 사용 방법

Issue 패널

• 애플리케이션 오류, 성능문제에 대한 정보 표시

• 환경에 따른 필터링 가능

• 하나의 이슈는 유사한 원인으로 그룹화된 에러들

• 이슈의 발생 빈도, 추이, 사용자별 영향도 파악 가능

일반적인 앱은 대량의 이벤트들을 센트리에 전송하게 되는데 수 많은 에러들이 전송되면서 이런 에러들을 필터링 및 그룹화해서 보여주지 않게되면 찾고하자는 메이저한 이슈 및 보고 있던 이슈들의 트래픽, 빈도, 상황 추이 등의 정보들을 픽해서 보기 쉽지 않기에 센트리는 이런 대량 이벤트들을 그룹핑해서 처리하게 된다.

Issue 상태

• New: 생성한지 7일 이내인 이슈

• Ongoing: 7일 이상 되었거나, 수동으로 reviewed 처리된 이슈

• Escalating: 오래된 이슈 중 빈도가 급격히 늘어난 이슈

• Regressed: resolved 되었다가 다시 나타난 이슈

• Archived: 보관처리된 이슈

• Resolved: 해결 처리된 이슈

Issue 탭

• Unresolved: 검토가 필요한, 아직 해결되지 않은 모든 이슈 총집합

• For Review: 검토 목록, 검토가 필요한 이슈, 해결되지 않은 이슈들의 하위 집합

• Regressed: 해결된 이슈, 해결된이슈가 다시 발생한 이슈

• Escalating: 이전에 archived 됬던 이슈 중 예상되는 이슈 빈도가 초과된 이슈

• Archived: 해결 처리된 이슈들

Issue 필터

• By Project

• By Environment

• By Time

• Custom filter

Issue 상세 패널

• 이슈 출처

• 영향 범위

• 그룹화된 이슈에 대한 요약

• 24시간/30일간의 빈도

• 관련 태그 정보

• Stack Trace

• Breadcrumbs

Session Replay 설정

• 공식문서
• Sentry.init() 내에 기록하는 설정 값

• 자동 설정시, sentry.client.config.ts/js 에 정의

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  // 오류 발생 시 녹화되는 리플레이의 샘플링 비율
  // 이 유형의 리플레이는 오류가 발생하기 전의 이벤트를 최대 1분까지 녹화
  // or 세션이 종료될 때까지 계속 녹화함
  // 1.0은 오류가 있는 모든 세션을 캡처하고 0은 안함 (0 ~ 1.0)
  replayOnErrorSampleRate: 1.0,
  // 사용자 세션 전체에 걸쳐 지속되는 리플레이의 샘플링 비율
  // 1.0은 모든 리플레이를 수집하고 0은 안함 (0 ~ 1.0)
  replaySessionSampleRate: 0.1,
  
  intergrations: [
    new Setnry.Replay({
      // 페이지 로딩 전반에 걸쳐 사용자를 추적
      // 탭당 세션 유지, 여러 탭을 사용하는 한 명의 사용자는 여러 세션으로 기록
      // 기본값: true
      stickySession: true,
      // SDK가 setnry로 전송을 시작하기 전까지의 리플레이 길이(ms)
      // max: 15000, default: 5000,
      minReplayDuration: 5000,
      // 모든 텍스트 컨텐츠를 마스킹처리
      maskAllText: true,
      // media element blocking
      blockAllMedia: true,
    })
  ]
})

Sampling Rate 설정하는 이유

• 매우 비쌈

• quota에 대한 이해에 기반

  • -> 사용량에 따른 과금 구조

• 일반 sentry error 보다 10배 이상의 가격

  • 꼭 필요한 부분에서만 도입 or 샘플링 비율 조정

Session Replay 패널

• 타임라인

• 플레이어

• Breadcrumbs

• 기타 컴포넌트 패널로 구분

• 페이지 액션

  • 리플레이 공유

  • 삭제