Нормально ли бросать (throw) внутри async функции?

Question

[Сергей Соколов]

Где-то читал, что нехорошо кидаться ошибками изнутри async функций — исключения только для совсем кривых ошибочных случаев. Мол, надо только возвращать rejected Promise.

Вожусь с React компонентом, который проходит цепочку асинхронных действий.
Процесс можно остановить кнопкой в любой момент. Для этого использую AbortController() чтобы останавливать асинхронные этапы работы со сторонним SDK или fetch() запросы на бэкенд.

Во многих местах кода, приходится вставлять одинаковые строки, что-то типа

await someAsyncSdkCall();

// не остановили ли?
if (this.isAborted()) {
  return promiseAborted();
}

довольно много раз получается одинаковый код – после каждого асинхронного вызова. Можно было бы сократить до однострочного this.throwIfAborted();

Что правильнее — повторять три строки десятки раз, или кидаться помётом изнутри async функции? Может, есть ещё способ проверять в цепочке асинхронных действий на каждом шаге, не пора ли всё бросить и уйти в отпуск?

Comments

[Алексей Уколов]

способ проверять в цепочке асинхронных действий на каждом шаге, не пора ли всё бросить

Можно каждый шаг обернуть в функцию, которая выполнит проверку и выполнит переданный код, если всё ок.

[Alexandroppolus]

как я понимаю, имеется что-то вроде такого?

async function f() {
  ...
  await f1();
  ...
  await f2();
  ...
  await f3();
  ...
}

и в каждой из этих функций надо отслеживать общий abortController?

[Сергей Соколов]

Alexandroppolus, да, примерно так. Внутри каждой из f1(), f2().. по нескольку async обращений к SDK или fetch() запросов на бэк.

[Alexandroppolus]

Сергей Соколов, ну тогда, по идее, fetch должен режектиться сам.
вызовы SDK, наверно, не умеют принимать abortController? тогда можно обернуть последний в промис (который будет режектиться по аборту), и этот промис присовокуплять, например, через Promise.race к вызовам SDK, либо просто написать для этих вызовов универсальную обертку с конструктором промиса, в котором отслеживать abortController, и работать с SDK уже через эту обертку.
Тогда не придется везде втыкать проверку - аборт в abortController вызовет reject в любой текущей асинхронной операции, и прервется вся цепочка.

Answer 1

[Максим Морев]

Где-то читал, что нехорошо кидаться ошибками изнутри async функций
... надо только возвращать rejected Promise.

В этом `где-то` вас обманули, так как любое возвращаемое из `async` функции значение (да, включая throw) уже обёрнуто в `Promise`.

const foo = async () => { throw new Error('Smth went wrong'); };
const bar = async () => Promise.reject(new Error('Smth went wrong'));

Работают абсолютно одинаково

Comments

[profesor08]

Работают абсолютно одинаково

Они не работают одинаково. Это разный, код, который работает по разному, и результат его выполнения тоже разный.
console.log(foo(), bar())

[Максим Морев]

profesor08, результат выполнения этого кода абсолютно одинаковый.

Ваш ответ тоже ценный, но отвечает на другой вопрос, здесь в тексте задачи слов `throw` и `reject` нет вообще.
Зато есть `return нечто, называемое rejected Promise`, внимание на слово return.

[profesor08]

Максим Морев, молоко черное...

Answer 2

[Roman K]

Идеологически нет ничего плохого в том, чтобы бросить ошибку в async функции. Она корректно разрушит флоу кода, если промис async функции вызывающая сторона await'ит. и не отловила Другое дело, что в JS промис можно не await'ить, бросание эксепшенов довольно дорогое (по времени) и вообще, эксепшены — это те же goto, только чуть более предсказуемые. Лучше кидаться rust-like контейнерами Result[T, E]. К тому же, их можно типизировать в TS, в отличии от эксепшенов

Answer 3

[profesor08]

throw бросит исключение, которое ты можешь обработать когда-то там потом, и гарантирует, что все дальнейшее исполнение будет прервано.

reject не бросает исключения и исполнение кода не прервется. Исключение будет выброшено когда-то там потом, когда промис этого захочет.

new Promise((resolve, reject) => {
  reject("reject msg");
  console.log("wtf?????");
})

Comments

[Сергей Соколов]

с reject() понятно – я же специально делал return Promise.reject(new Error('Aborted')); так, что никакого дальнейшего выполнения.

Повтор одинаковых строк сквозь код мне кажется неправильным, и даже сокращение до 1 строки, которая бросает throw, но повторяется после каждой асинхронной операции – вроде бы, неверно. Очень хорошее решение с обёрткой каждой «отменяемой» асинхроты в Promise.race() подсказал в комментариях Alexandroppolus – так и поступлю.

[profesor08]

В любом случае придется проверять данные, и если данные разные, то и проверять придется все по разному. От однотипных вещей никуда не денешься. AbortController() позволит тебе отменить запросы, а значит можно будет перехватить это дело с помощью try catch, достаточно передать сигнал в запрос. А потом уже бросить более осмысленное исключение, для каждого промиса свое. reject задуман для того, чтоб можно было завершить промис с ошибкой из самого колбека и иметь возможно сделать что-то там еще внутри колбека, это старое апи, придуманное до async/await. Сейчас же все прекрасно интегрировано с исключениями, и в асинхронных функциях использовать reject нет смысла, потому что этот reject не будет связан контекстом с асинхронной функцией, это будет отдельный новый промис который отменили.