[❗️Error] 커스텀 에러와 에러 관심사 분리

💡 오늘도 javascript가 안된다고 했다

최근에 드로잉 관련한 기능 하나를 개발하고 있던 도중, 에러가 발생했는데 이것을 제대로 캐치하지 않아서 앱이 터지는 상황이 벌어졌었다.

사실 IndexedDB라는 것을 처음 사용하다보니, 이 녀석이 가지고 있는 onError 콜백 핸들러가 당연히 에러를 잡아줄거라고 생각했던 것이 바보였다.

 const saveTransaction = (tableName: string, data: any, type: 'put' | 'add' = 'add') => {
      if (database === null) {
        throw new Error('no database');
      }

      const transaction =  database.transaction(tableName, 'readwrite');
      const table = transaction.objectStore(tableName);
      const request = type === 'add' ? table.add(data) : table.put(data);
      request.onsuccess = () => console.log('save success');
      request.onerror = (e) => {
        console.error('no suffient space to save data');
        setMemoImpossible();
      };
}

위 코드는 드로잉했던 내용을 Save하는 로직이 담겨있는 핸들러이다.
IndexedDB는 간단히 설명하면 웹에서 사용할 수 있는 데이터 스토리지로, 다음과 같은 장점이 있다.

1. 로컬 스토리지와 다르게 저장 공간이 브라우저별로 상이하지만 매우 크고 직렬화 불가능한 값들을 제외한 거의 모든 값들을 저장할 수 있다.
2. Key-Value로 이루어진 B-tree 자료구조의 Database형태를 띄고 있고, transaction 개념을 통해 안전하게 데이터를 CRUD 하는 것이 가능하다.
3. 거의 영속적으로 데이터가 저장되어 클라이언트별로 각자 독립적인 데이터를 유지할 수 있다.

IndexedDB에 대한 더 자세한 설명은 구글 성님의 웹 스토리지들에 대한 설명 을 참조하면 좋다

여기서 문제점은 위 코드에서 보이는 "database.transaction(tableName, 'readwrite');" 와 같은 코드들에 있다.

위에서도 언급했듯이, IndexedDB는 Transaction을 기반으로 데이터를 관리하는 시스템이다.

Transaction이란 항상 성공하거나, 항상 실패해야 하는 로직들의 단위 모음이다.
(예를 들어, 결제하기를 실행한다면 "데이터조회 => 잔액 확인 => 결제 확인 => 결제 결과 저장" 처럼 모든 프로세스가 하나라도 실패할 경우 전부 실패로 여겨져서 롤백되어야 하는 것과 같이 하나의 단위로 로직들이 연결되어 처리되는 구조를 뜻한다)

그런데 우연하게 인자로 잘못된 값이 들어가도 onError가 잡아주는지 확인해보고 싶어서

database.transaction('none', 'readwrite') // 없는 테이블 네임으로 트렌잭션 인스턴스 초기화해봄.

위의 방식으로 코드를 짜서 save 를 호출해봤더니 웬걸?

시원하게 터져버리는 것이었다.

💡 너무나 당연한 소리긴 했지만

애초에 잘못된 인자가 들어갔을 때 함수가 호출을 실패해서 throw를 던져질 것임을 인식했어야 했던 것을, onError 콜백 핸들러가 있으니 알아서 해주겠지 뭐(후비적) 하고 안일하게 생각했던 내가 바보였다.

그런데 이를 해결하려고 보니, 조금 문제점이 발생하였다.

단순하게 try~catch를 사용하려고 보니, 코드가 너무 지저분하고 난잡해져서 읽기가 점점 어려워지는 상황이 벌어지는 것이다.

예전에 Backend 결제시스템 관련 라우터를 작성할때도 느꼈던 것이지만, 각 로직별로 try~catch 가 존재해버리면 블록 스코프의 한계점으로 인해 스코프 바깥에서 해당 값을 읽어들이기 위해서는 저렇게 비효율적인 변수 선언이 반복되야 하는 상황이 발생했다.

저기 저 위에 let들의 더미들이 보이는가... 저게 과연 한두개가 아니라 수십개가 되는 순간이 오면? 생각만해도 끔찍하다.

그래서, 이런 식으로 각 에러가 발생할 지점을 관리하는 것이 너무 불만족스러웠던 터라 아예 함수블록 하나에 Try~catch를 두고, 모든 catch문에서 에러를 통합관리하자는 이야기가 있었었다.

그런데, 그것 역시 너무 지저분하기 그지없다.
사실 내가 판단할 수 있는 에러 외에도 너무나 많은 에러가 존재하고, 이것을 처리할 로직을 다 catch에 때려박고 있으니 점점 확인이 어려워져가는 문제점이 발생하는 것이었다.

includes의 빨간줄은 살짝 눈감고 지나가주시길... 현재 프로젝트 폴더에 모듈 설치를 안해놓은 상태라서 그렇다.

여튼, 위의 사진에서 보면 알 수 있지만 생각해야 할 에러가 많아지면 많아질수록 catch블록 역시 점점 지저분해지기 시작한다.

정작 내가 하고 싶은 건, 각 에러가 예상되는 지점의 로직별로 제각각의 에러 핸들링을 하도록 만들고 외부 로직과 에러 핸들링에 대한 관심사를 분리하는 것이 목표였던 것이다.

💡 모든 경험은 개발의 아하모먼트가 된다

그러면 어떤 식으로 에러를 핸들링하는 게 가장 깔끔한 로직이 될 것인가.. 에 대하여 고민하던 도중,최근에 원티드 프리온보딩 with Next.js를 신청해서 들었던 강의내용 중 떠오른게 있었다.

내용 중 과제로 SPA router 직접구현하는 커리큘럼이 있었다.

root.render(
  <Router>
  	<Routes>
      <Route path="/" component={<Root />} />
      <Route path="/about" component={<About />} />
  	</Routes>
  </Router>
);

해당 구현을 하면서 염두해둬야 했던 핵심은 아래와 같았다.

1. Route는 props로 자신의 경로에 대한 path 값과, 리턴해줄 컴포넌트를 건네받는 컴포넌트이다. (순수함수, 딱 그 역할만 한다.)

2. Routes는 현재 Path를 보고 어떤 자식을 랜더링해야 할 지를 담당한다.

3. Router은 경로변경을 감지하고 이를 window API를 활용하여 브라우저의 path를 변경하고 이 값을 자식들에게 전파하는 역할을 한다.

이 과제를 하기 전까지는, 관심사분리 라는 개념에 대해서 머릿속에 넣어두기만 하고
"응 그래 관심사 분리해야지 허허허허" 라는 느낌처럼 개발을 해왔다가,

이 경험을 토대로 진짜 역량이 부족해서 티끌만큼이었지만 그래도 관심사 분리가 얼마나 중요한 것인지를 깨닫는 "아하 모먼트"를 겪게 되었다.

실제 라우팅 시스템은 나중에 추가되게 되는 SSR의 환경에서도 사용될 수 있어야 하기 때문에 더욱 관심사가 분리되어야 작성되어가고, 그 덕택에 확장이 가능하다는 설명을 듣고 나서 더욱 더 그러하였다.

그리고 나서 이 경험이 갑자기 머릿속에 떠올라서 에러 핸들링도 이렇게 관심사가 분리되어서 작성되면 되지 않을까 하는 생각이 들게 되었다.

즉, 애초부터 실제 로직 부분에서는 에러 핸들링과 관련한 로직들이 try~catch로 노출되어 있을 필요성이 굳이 있을까... 하는 생각이 든 것이다.

그럴 필요가 없다면, 각 로직의 에러 핸들링에 대한 담당 부분은 마치 은닉화처럼 내부 로직으로 스며들어 있고, 실제 개발자가 관심을 가져야 하는 것은 외부로 노출되는 로직만 남겨져있으면 된다는 생각이 들었다.

💡 거두절미하고 구현은 아래와 같다

📦 src
├── 📂 Error
│   ├── 📄 index.ts
│   └── 📄 indexedDB.ts

// index.ts
export type BaseErrorCase<T> = (err: Error & { name: T }) => Error; // 호출당시가 아닌, 할당 내용에 타입정의이므로 할당하는 장소에서 타입 정의해야 함 (generic T 위치가 좌측). 공적사용을 위해 index.ts에서 export함
export type Closure = <T extends (...args: any) => any>(targetFunc: T) => ReturnType<T>; // 호출 당시 타입이 인자에 의해 정해지므로, T를 extends할 때 일반화 타입으로 확장함. (generic T 위치가 우측)

export class CustomError extends Error { //커스텀 에러 객체를 만드는 클래스
  constructor(readonly message: string, public name: string) {
    super(message);
    this.name = name;
  }
}

export const customErrHandlerGenerator = (targetErrName: string, message: string = '') =>
  ((targetFunc) => {
    // customErrWrapperGenerator은 CustomError을 생성해 내보내는 관심사를 담당한다.
    try {
      return targetFunc();
    } catch (err) {
      throw new CustomError(message, targetErrName); // 받아오는 에러객체가 아닌, 커스텀 에러객체를 throw
    }
  }) as Closure;

export const customErrorBoundaryGenerator =
  (errorCase: (err: Error) => void) => (customErrHandler: ReturnType<typeof customErrHandlerGenerator>) =>
    ((targetFunc) => {
      // customErrorBoundaryGenerator는 customError의 분기를 처리하는 관심사를 담당한다.
      try {
        return customErrHandler(targetFunc);
      } catch (err) {
        errorCase(err);
      }
    }) as Closure;

🕹 <index.ts>

index.ts에는 공통 에러를 만들어주는 로직들을 장착하였다.

CustomError 클래스는 단순하게 message와 name을 받아서 "내가 관리하고자 마음먹은 name을 가진 에러객체" 를 생성하는 관심을 담당한다.

커스텀 에러 객체와 관련한 내용은 커스텀 에러 만들어보기 를 읽어보다가 힌트를 얻었다.

customErrHandlerGenerator 함수와 customErrorBoundaryGenerator 함수는 커링 함수와 관련된 내용을 읽어보다가 힌트를 얻었다.

두 함수가 갖는 관심사는 아래와 같았다.

• customErrHandlerGenerator의 관심사 : CustomError 클래스를 참조하여 스코프 체인으로 가지고 있다가, 호출되는 시점에서 해당 작업이 실패할 경우 커스텀 에러를 생성하여 throw하는 클로져를 리턴한다.
• customErrorBoundaryGenerator의 관심사 : 인자로 받을 errorCase를 참조하여 스코프 체인으로 가지고 있다가, 호출되는 시점에서 헬퍼 함수로 받게 되는 customErrHandler가 실패할 경우 가지고 있던 errorCase 함수를 호출해서 적절한 처리를 하는 클로져를 리턴한다.

결국은,

1. 커스텀 에러를 만들어서 이것을 throw하는 로직과 (마치 Route처럼)
2. 전파되는 에러 객체를 캐치하여 처리하는 로직 (마치 Routes처럼)

위에 적어놓고 보니 무슨 소린가 싶은데, 이것들을 모듈로 가져와 확장하는 측(indexedDB.ts)을 보면 더 이해가기가 쉽다.

참고로 커링함수로 작성한 이유도 외부 컨텍스트에 존재하는 내용을 갖고 있다가 모듈로서 import되어 사용될 때 참조될 수 있도록 하려고 해서 만들어진 형태이다.

🕹 <indexedDB.ts>

import { BaseErrorCase, customErrHandlerGenerator, customErrorBoundaryGenerator } from 'Error';

type ErrorName = (typeof errorNameEnum)[keyof typeof errorNameEnum];
type ErrorCase = BaseErrorCase<ErrorName>;

const errorNameEnum = {
  transactionError: 'transactionError',
  objectStoreError: 'objectStoreError',
} as const;

const errorCase: ErrorCase = (err) => {
  if (err.name === 'transactionError') {
    console.error(`${err.name} 이 발생했습니다`, err);
  }

  if (err.name === 'objectStoreError') {
    console.error(`${err.name} 이 발생했습니다`, err);
  }

  throw err; //무조건 err를 다시 던지게 하여, 부모 로직에서 이 함수 호출 이후의 로직을 하지 않도록 block한다.
};

const customErrorBoundary = customErrorBoundaryGenerator(errorCase); // errorCase는 공통분모인 분기점이므로, 한번만 스코프 환경에 등록하고 이후는 리턴되는 함수를 재활용한다.

export const handleTransactionErr = customErrorBoundary(customErrHandlerGenerator(errorNameEnum.transactionError));
export const handleObjectStoreErr = customErrorBoundary(customErrHandlerGenerator(errorNameEnum.objectStoreError));

각 파일에는 어떤 에러들을 내가 직접 타겟팅하여 관리할 것인지에 대한 내용이 작성되어 있다.

위에 작성했던 것처럼, customErrorBoundaryGenerator은 인자로 에러케이스를 받아서 이것을 컨텍스트적으로 가지고 있는다.

리턴되는 함수는

// 외부 스코프 환경에는 errorCase 함수가 참조되고 있음.
 const customErrorBoundary = (customErrHandler: ReturnType<typeof customErrHandlerGenerator>) =>
    ((targetFunc) => {
      try {
        return customErrHandler(targetFunc);
      } catch (err) {
        errorCase(err);
      }
    }) as Closure;

가 된다. 이제 해당 함수로 래핑할 경우, 리턴되는 함수는 자식으로부터 throw하여 전파되는 커스텀 에러객체를 errorCase로 처리가 가능한 클로저가 된다.

그리고 래핑한 내용들이 바로

export const handleTransactionErr = customErrorBoundary(customErrHandlerGenerator(errorNameEnum.transactionError));
export const handleObjectStoreErr = customErrorBoundary(customErrHandlerGenerator(errorNameEnum.objectStoreError));

가 되는 것이다.

이제 이 함수를 모듈로 export하여 내가 직접 타겟팅하여 관리하길 원하는 로직에 감싸주면 된다.

사용되는 측에서는 더이상 불필요한 try~catch 로직을 볼 필요가 없어졌다.
래핑하는 함수가 그 관심사를 처리해주는 것이다!

이렇게 에러를 처리했을 경우 가장 큰 장점은 역시 개인적으로 불필요한 관심사가 노출되지 않는다는 장점도 있지만 더 큰 것은, 내가 어떤 에러를 알아야 하는지를 알 필요가 없어진다는 점이다.

애초에 저 database.transaction이 실패했을 때 만들어지는 err객체의 타입이 무엇인지 나는 신경쓸 필요가없다. 왜냐면 걔가 뭘 던지든 말든 나는

// customErrHandlerGenerator
 try {
      return targetFunc();
    } catch (err) { //너가 뭘 던지든간에...
      throw new CustomError(message, targetErrName); // 받아오는 에러객체가 아닌, 커스텀 에러객체를 throw
    }

이러기 때문이다. 예전 백엔드 로직때 하나하나 케이스를 다 확인하면서 분기처리했던 고통을 다시금 기억하며, 현재 로직에 아주 뿌듯함을 느낀다.

💡 맺음글

아직 보완점이 많은 로직이지만, 그래도 필요한 목적을 달성한 것 같아서 너무 마음에 든다.

그리고 이렇게 정리하고 보니까 느끼는 것이지만, 개발자로서 어떤 공부를 하든 어떤 로직을 작성하게 되든 그것은 다 발전의 양분으로 쓰이게 된다는 사실을 다시금 깨닫게 된다.

오랜만에 개발새싹에 물을 주게 되는 시간이었다.