Object.setPrototypeOf

파편화된 에러를 정적 팩토리 메서드로 묶어주는 작업을 진행하고 있다.
에러의 생성자를 확인하여 분기처리를 하는 과정에서 명시적으로 체이닝 된 프로토타입을 변경 해줘야하나 의문이 생겼다.

Object.setPrototypeOf(this, new.target.prototype);

이에 대한 테스트를 간단하게 진행한 내용이다.

결론 : 동적으로 Error에 대한 프로토타입이 변경되지 않고, 단순히 instanceof를 이용해 에러 분기처리를 진행하는 용도라면 하지 않는 것이 좋음. (성능 저하 및 광범위한 사이드 이펙트 가능성 있음)

---

기본 Error

class CustomError extends Error {
  constructor(message, ...args) {
    super(message, ...args);
  }
}

class NewProtoChainError extends Error {
  constructor(message, ...args) {
    super(message, ...args);
    Object.setPrototypeOf(this, new.target.prototype);
  }
}

const createError = (message, error) => {
  try {
    throw new error(message);
  } catch (err) {
    console.log(`isInstanceOfError: ${err instanceof Error}`);
    console.log(`isInstanceOfCustomError: ${err instanceof CustomError}`);
    console.log(`isInstanceOfNewProtoChainError: ${err instanceof NewProtoChainError}`);
  }
};

---

결과 비교

Error

createError('test', Error);

VM2120:19 isInstanceOfError: true
VM2120:20 isInstanceOfCustomError: false
VM2120:21 isInstanceOfNewProtoChainError: false

CustomError

createError('test', CustomError);

VM2120:19 isInstanceOfError: true
VM2120:20 isInstanceOfCustomError: true
VM2120:21 isInstanceOfNewProtoChainError: false

CustomError with PrototypeChaining

createError('test', NewProtoChainError);

VM2120:19 isInstanceOfError: true
VM2120:20 isInstanceOfCustomError: false
VM2120:21 isInstanceOfNewProtoChainError: true

에러의 프로토타입이 동적으로 변경되어야 하는 경우(가 있을지는 아직 모르겠지만)가 아니라 단순히 instanceof로 에러에 대한 분기처리를 진행하는 경우라면 명시적으로 프로토타입을 체이닝하지 않아도 상관이 없다.

또한, 성능적 측면에서 손실이 크고, 사이드 이펙트가 강하기 때문에 최대한 피하는 것이 좋아보인다.

> MDN - Object.setPrototypeOf()