prefer-promise-reject-errors

Требуйте использовать объекты Error в качестве причин отклонения Promise

Считается хорошей практикой передавать функции reject() для пользовательских ошибок в Promise только экземпляры встроенного объекта Error. Объекты Error автоматически сохраняют трассировку стека, которую можно использовать для отладки ошибки, определив, откуда она произошла. Если Promise отклонён со значением, не являющимся Error, может быть трудно определить, где произошло отклонение.

Описание правила

Это правило призвано гарантировать, что Promise отклоняются только с объектами Error.

Параметры

Это правило принимает один необязательный аргумент-объект:

• allowEmptyReject: true (по умолчанию — false) разрешает вызовы Promise.reject() без аргументов.

Примеры неправильного кода для этого правила:

/*eslint prefer-promise-reject-errors: "error"*/

Promise.reject("something bad happened");

Promise.reject(5);

Promise.reject();

new Promise(function(resolve, reject) {
  reject("something bad happened");
});

new Promise(function(resolve, reject) {
  reject();
});

Примеры правильного кода для этого правила:

/*eslint prefer-promise-reject-errors: "error"*/

Promise.reject(new Error("something bad happened"));

Promise.reject(new TypeError("something bad happened"));

new Promise(function(resolve, reject) {
  reject(new Error("something bad happened"));
});

const foo = getUnknownValue();
Promise.reject(foo);

Примеры правильного кода для этого правила с параметром allowEmptyReject: true:

/*eslint prefer-promise-reject-errors: ["error", {"allowEmptyReject": true}]*/

Promise.reject();

new Promise(function(resolve, reject) {
  reject();
});

Известные ограничения

Из-за ограничений статического анализа это правило не может гарантировать, что вы будете отклонять Promise только с объектами Error. Правило сообщит о случаях, когда можно гарантировать, что причина отклонения явно не является Error, но не сообщит о случаях, когда нет уверенности в том, является ли указанная причина Error. Подробнее об этом ограничении см. в разделе аналогичные ограничения правила no-throw-literal.

Во избежание конфликтов между правилами это правило не сообщает о значениях, не являющихся ошибками, используемых в инструкциях throw асинхронных функций, хотя они и приводят к отклонению Promise. Чтобы проверять такие случаи, используйте правило no-throw-literal.

Когда не следует использовать это правило

Если вы используете пользовательские значения, не являющиеся ошибками, в качестве причин отклонения Promise, это правило можно отключить.

Связанные правила

• no-throw-literal

Версия

Это правило появилось в ESLint v3.14.0.

Дополнительная литература

Ресурсы

• Исходный код правила
• Исходный код тестов