[Feature] Sentry 도입, 커스텀 에러 HTTPError 객체 생성을 통한 에러 이벤트에 대한 분리

[wuzoo]

해당 이슈 번호

closed #212

---

체크리스트

• 🔀 PR 제목의 형식을 잘 작성했나요? e.g. [feat] PR을 등록한다.
• 💯 테스트는 잘 통과했나요?
• 🏗️ 빌드는 성공했나요?
• 🧹 불필요한 코드는 제거했나요?
• ✅ 컨벤션을 지켰나요?
• 💭 이슈는 등록했나요?
• 🏷️ 라벨은 등록했나요?
• 💻 git rebase를 사용했나요?
• 🙇‍♂️ 리뷰어를 지정했나요?

---

🤍 Sentry 사용하기 & 참고 사항

Sentry

먼저 슬랙에도 말씀드렸다시피, Sentry를 도입하였습니다. 제가 해당 툴을 도입하기 전 말씀드렸던 도입 근거와 비교했을 때, 실제로 사용해보니 좋았던 점은 먼저 다음과 같습니다.

1. 실제로 로그되는 에러들에 대해서, 상세적으로 알 수 있는 정보가 너무 많아서 좋았습니다.
2. 현재 에러바운더리와 인터셉터에 Sentry를 통해 이벤트를 감지하고 메세지를 보내는 로직을 추가하였습니다. 따라서 문법 오류, 로직 오류, API 오류, 예상치 못한 오류 등 대부분의 에러를 Sentry를 통해 확인 가능했습니다.

위에서와 같이 issues 페이지로 들어가보면 현재까지 찍힌 에러들, 그리고 상세 정보들을 확인 가능합니다.

먼저 제가 Sentry 저희 tiki-web 팀에 대한 초대 메일을 발송해드렸는데, 이거 받으시면 지금까지 로컬 환경에서 발생하는 에러 로그들을 모두 확인할 수 있고, 현재 sourcemaps 설정을 통해서 배포 환경에서도 아마 정상적으로 작동할 것입니다. (pr 날려서 cd가 되면 배포환경에서 한번 확인해보겠습니다.)

HTTPError 에러 객체 구현

export class HTTPError extends Error {
  statusCode: number;

  code?: number;

  constructor(statusCode: number, mesaage?: string, code?: number) {
    super(mesaage);

    let name = 'HTTPError';

    switch (statusCode) {
      case HTTP_STATUS_CODE.BAD_REQUEST: {
        name += ': BAD_REQUESET';
        break;
      }
      case HTTP_STATUS_CODE.UNAUTHORIZED: {
        name += ': UNAUTHORIZED';
        break;
      }
      case HTTP_STATUS_CODE.FORBIDDEN: {
        name += ': FORBIDDEN';
        break;
      }
      case HTTP_STATUS_CODE.NOT_FOUND: {
        name += ': NOT_FOUND';
        break;
      }
      case HTTP_STATUS_CODE.CONTENT_TOO_LARGE: {
        name += ': CONTENT_TOO_LARGE';
        break;
      }
      case HTTP_STATUS_CODE.INTERNAL_SERVER_ERROR: {
        name += ': INTERNAL_SERVER_ERROR';
        break;
      }
    }

    this.name = name;
    this.statusCode = statusCode;
    this.code = code;
  }
}

먼저 구현 코드입니다. 먼저 당연히 빌트인 에러 객체를 상속합니다. 따라서 기존의 에러 객체와 동일하게 HTTPError를 throw 한다면 에러바운더리에서 에러를 캐치할 수 있을 것입니다.
하지만 참고하셔야할 사항은 기본적으로 에러바운더리는 비동기 통신에서 발생한 에러를 캐치하지 못한다는 점입니다. 물론 unhandledrejection이라는 이벤트를 통해서 캐치할 수 있도록 만들 수는 있는데, api 요청 간에 에러가 발생한다고 하여도 어플리케이션이 터지면 안되므로, 기본적인 에러 바운더리 세팅만 해두었습니다.

그 대신 HTTPError 커스텀 에러 객체를 생성하여, 발생한 에러 객체 속에서 API Error인지 아니면 일반적인 에러인지를 파악할 수 있도록 하였고, Sentry에도 이를 구분하여 로그하도록 설정해두었습니다.

• 추가적으로, 서버와도 논의된 사항 중에 특히 인증과 관련된 에러 처리에서 error code를 좀 더 세분화하기로 결정했는데요. 즉 "유효하지 않은 토큰" 혹은 "만료된 토큰" 등 에러 코드를 세분화하여 응답 받을 예정입니다. 아마도 서버 쪽에서 구현 완료된다면 에러 처리 관련 코드가 조금은 수정될 수도 있을 것 같습니다.

[rtttr1]

참 또 혼자서 어려운거 뚝딱뚝딱 다 해오셨네요.. 대박.. 왜 이렇게 잘하세요 진짜? 얼른 에러 터트려서 저도 sentry로 에러코드 봐보고 싶네요!! 고생 많으셨습니다 정말!!!

[cindy-chaewon]

우와... 수고하셨습니다!! sentry 열심히 활용해보겠습니다!!

[namdaeun]

LGTM Sentry 도입한 덕분에 앞으로 에러 추적이 훨씬 편해질 것 같아요!
세팅 고생 많으셨습니다 :)

[namdaeun]

message로 오타 수정해줍시당 !

[wuzoo]

헉 넵 수정했습니다 !