Как стать автором
Обновить

Комментарии 12

Имхо ровно наоборот, ибо под async/await лежат как раз промисы
Да. но ты сначала показываешь человеку

try{ 
  let users = apiClient.getUsers();
} 
catch (e) {
 ...
}


А потом уже можно рассказывать про то, что там под капотом промисы на самом деле.
Если вы действительно хотите человека чему-то научить, но надо действовать от простого к сложному, итеративно.
Я, кстати, не думаю, что с появлением async/await люди часто продолжают писать .then

Я, кстати, не думаю, что с появлением async/await люди часто продолжают писать .then

Ради интереса посмотрел в своих текущих проектах: 39 .then(, 403 await. Правда слоновья доля await в тестах. В самих проектах в основном всё синхронно и почти вся асинхронщина на nodejs-сервере.

НЛО прилетело и опубликовало эту надпись здесь
А ничего, что finally пока что в Stage 4? Хоть бы упомянули об этом.
Дак вроде как это вошло в уже в ES2018
Так он тоже отнюдь не везде поддерживается.
Во первых, статья про язык, а не про то где какие его фичи поддерживаются.

Во вторых, это не проблема, берете babel и вперед.
Для обработки ситуации успешного разрешения промиса используйте метод .then, для тех случаев, когда промис отклонён, применяйте .catch.


Это немножко неосторожный совет.
Например, пишем:
промис.then(обработчик1).catch(обработчик2)

Верно ли, что в обработчик2 мы попадаем тогда и только тогда, когда исходный промис отклонён?
Нет, мы попадём туда, когда отклонён промис промис.then(обработчик1), то есть и в том случае, когда исходный промис выполнен, а в обработчик1 брошена ошибка.
То есть это не эквивалентно
промис.then(обработчик1, обработчик2)

Использовать catch следует с осторожностью.
Да, эти конструкции не эквивалентны. Тем не менее, обычно именно это и нужно: отловить любую ошибку, в том числе возникшую уже в первом обработчике. Потому-то и советуют заменять двойной then на catch.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий