더 똑똑한 던지기

async/await가 내 많은 코드에 대한 표준 절차가 되면서 오류를 제대로 처리하고 있는지 확인하기 위해 try/catch에 코드 블록을 래핑하고 있습니다.

그 결과, 이 미니 포스트에서 보여주고 싶은 것과 동시에 내 오류를 조금 더 유용하게 만들려고 노력합니다.

예

일련의 명령문을 실행하고 특정 문제와 규칙을 확인하는 대규모 검증 프로세스가 있습니다.

각 유효성 검사 규칙이 실행되고 실패하면 다음과 같은 메시지가 발생합니다.

export function validateFakeExample(token, scope) {
  if (token.text !== 'PRINT') return;

  const next = scope.peekNext();
  if (next.name !== AT) {
    throw new Error('Parser error, PRINT keyword should be followed by AT');
  }
}

내 주요 기능은 사용자가 오류의 원인을 이해하는 데 도움이 되는 추가 메타데이터도 캡처하기를 원하기 때문에 try/catch 내부에 모두 캡슐화된 각 유효성 검사 규칙을 실행합니다.

그래서 내 포장 catch에는 다음과 같은 것이 있습니다.

} catch (error) {
  const message = error.message + `, "${token.text}" at: ${token.pos + 1}`;
  throw new Error(message);
}

이렇게 하면 내 사용자에게 오류가 다시 표시될 때 다음과 같이 표시됩니다.

Parser error, PRINT keyword should be followed by AT, "INK" at: 10

실제로 저는 이 패턴을 많이 사용하여 소스 오류를 포착하고 해석하고throw new Error 무슨 일이 일어나고 있는지 더 잘 이해할 수 있도록 도와줍니다.

더 똑똑할 수 있다는 점만 빼면요.

똑똑해지기

new Error를 호출하면 새로운 오류 개체가 생성됩니다. 이 시점에서 몇 가지 일이 발생합니다. 특히 스택이 캡처됩니다. 스택 추적은 문제의 원인을 추적하는 디버깅에 매우 유용합니다.

단, 새로운 오류를 생성했기 때문에 내 스택 추적은 catch 내에서 시작됩니다. 이는 어느 정도 도움이 되지만 훨씬 더 유용할 수 있습니다.

스택으로 뭔가를 할 수 있습니다. 때때로 내 로그를 검색할 수 있는 console.log(error.stack)에 catch를 추가했습니다.

내가해야 할 일은 new Error를 던지는 대신 원래 error.message 속성을 간단히 수정할 수 있습니다 (🤦 왜 그렇게 오래 걸렸습니까).

이제 내 코드는 다음과 같습니다.

} catch (error) {
  error.message += `, "${token.text}" at: ${token.pos + 1}`;
  throw error;
}

내 사용자 정의 오류 메시지가 사용자(보통 나)에게 전달되고 전체 스택 추적이 유지됩니다.

원래 발행일Remy Sharp's b:log