Js почему вс код подчеркивает необработанный промис

7

Промисы: обработка ошибок

Цепочки промисов отлично подходят для перехвата ошибок. Если промис завершается с ошибкой, то управление переходит в ближайший обработчик ошибок. На практике это очень удобно.

Например, в представленном ниже примере для fetch указана неправильная ссылка (сайт не существует), и .catch перехватывает ошибку:

Как видно, .catch не обязательно должен быть сразу после ошибки, он может быть далее, после одного или даже нескольких .then

Или, может быть, с сервером всё в порядке, но в ответе мы получим некорректный JSON. Самый лёгкий путь перехватить все ошибки – это добавить .catch в конец цепочки:

Если все в порядке, то такой .catch вообще не выполнится. Но если любой из промисов будет отклонён (проблемы с сетью или некорректная json-строка, или что угодно другое), то ошибка будет перехвачена.

Неявный try…catch

Вокруг функции промиса и обработчиков находится "невидимый try..catch ". Если происходит исключение, то оно перехватывается, и промис считается отклонённым с этой ошибкой.

Например, этот код:

…Работает так же, как и этот:

"Невидимый try..catch " вокруг промиса автоматически перехватывает ошибку и превращает её в отклонённый промис.

Это работает не только в функции промиса, но и в обработчиках. Если мы бросим ошибку ( throw ) из обработчика ( .then ), то промис будет считаться отклонённым, и управление перейдёт к ближайшему обработчику ошибок.

Это происходит для всех ошибок, не только для тех, которые вызваны оператором throw . Например, программная ошибка:

Финальный .catch перехватывает как промисы, в которых вызван reject , так и случайные ошибки в обработчиках.

Пробрасывание ошибок

Как мы уже заметили, .catch ведёт себя как try..catch . Мы можем иметь столько обработчиков .then , сколько мы хотим, и затем использовать один .catch в конце, чтобы перехватить ошибки из всех обработчиков.

В обычном try..catch мы можем проанализировать ошибку и повторно пробросить дальше, если не можем её обработать. То же самое возможно для промисов.

Если мы пробросим ( throw ) ошибку внутри блока .catch , то управление перейдёт к следующему ближайшему обработчику ошибок. А если мы обработаем ошибку и завершим работу обработчика нормально, то продолжит работу ближайший успешный обработчик .then .

В примере ниже .catch успешно обрабатывает ошибку:

Здесь блок .catch завершается нормально. Поэтому вызывается следующий успешный обработчик .then .

В примере ниже мы видим другую ситуацию с блоком .catch . Обработчик (*) перехватывает ошибку и не может обработать её (например, он знает как обработать только URIError ), поэтому ошибка пробрасывается далее:

Управление переходит от первого блока .catch (*) к следующему (**) , вниз по цепочке.

Необработанные ошибки

Что произойдёт, если ошибка не будет обработана? Например, мы просто забыли добавить .catch в конец цепочки, как здесь:

В случае ошибки выполнение должно перейти к ближайшему обработчику ошибок. Но в примере выше нет никакого обработчика. Поэтому ошибка как бы «застревает», её некому обработать.

На практике, как и при обычных необработанных ошибках в коде, это означает, что что-то пошло сильно не так.

Что происходит, когда обычная ошибка не перехвачена try..catch ? Скрипт умирает с сообщением в консоли. Похожее происходит и в случае необработанной ошибки промиса.

JavaScript-движок отслеживает такие ситуации и генерирует в этом случае глобальную ошибку. Вы можете увидеть её в консоли, если запустите пример выше.

В браузере мы можем поймать такие ошибки, используя событие unhandledrejection :

Это событие является частью стандарта HTML.

Если происходит ошибка, и отсутствует её обработчик, то генерируется событие unhandledrejection , и соответствующий объект event содержит информацию об ошибке.

Обычно такие ошибки неустранимы, поэтому лучше всего – информировать пользователя о проблеме и, возможно, отправить информацию об ошибке на сервер.

Why does VS Code break on handled exception from Reject in Promise?

Take this code, we have a promise that calls a function that will fail, and it should pass the error onward to the catch method of the promise.
It works just fine when ran from the terminal. However when ran through vscode it explodes at (1).

vscode about page:
Version 1.14.2
Commit cb82feb
Date 2017-07-19T23:26:08.116Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

1 Answer 1

Solution

As @T.J.Crowder pointed out in the comments:

This only happens when an exception is thrown causing a rejection before a handler is attached. E.g., this wouldn’t cause it, because when the exception is converted to rejection, there’s already a rejection handler attached:

Turns out this is a known «bug» when using vscode to debug Nodejs. As its explained in this issue (over at the vscode git repository) this happens because Nodejs send a break-event with an undefined exception when ever it encounters a reject callback. When vscode’s debugger sees this break-event it does what its supposed to do with unknown exceptions, it pauses the execution and then throws the exception.
Further more in this issue (over at the vscode-node-debug2 repository) @roblourens says that:

If a promise is rejected before an error handler is attached, the debugger will break, even if only «uncaught exceptions» is checked. If it’s rejected after the error handler is attached, it works as expected. And really the problem is the way the promise doesn’t know whether its rejection will be handled or not.

You can still use vscode for developing Promise based systems, however you will need to turn off all error handling in vscode, as seen below make sure neither of the options are ticked. NOTE: Since this is far from an optimal solution, it is likely to get changed and or improved in the future.

(I’ve commented on the vscode issue and will update this post if I learn anything useful)

Edit1:
I’ve found that another workaround is to define a keybinding in vscode to run the command workbench.action.debug.run . This will run the current selected debug option without attaching the debugger to it. This means that you can keep the debugger on your normal settings, while running the code using the new key command when you need to work with rejected promises.

Edit2:
As @T.J.Crowder pointed out in the comments:

This only happens when an exception is thrown causing a rejection before a handler is attached. E.g., this wouldn’t cause it, because when the exception is converted to rejection, there’s already a rejection handler attached:

And of course he was right. The code below does work in vscode with the debugger attached.

Поиск проблемных промисов в JavaScript

JavaScript — это фантастический язык для серверного программирования, так как он поддерживает асинхронное выполнение кода. Но это ещё и усложняет его использование.

Асинхронность означает возможность написания кода, который не подвержен обычным проблемам, связанным с потокобезопасностью, и поддерживает выполнение множества задач в «параллельном» режиме. Например — ожидание считывания файла не блокирует другие вычисления.

Но небольшие ошибки в асинхронном коде могут приводить к появлению неразрешённых промисов. То есть — к участкам кода, выполнение которых, однажды начавшись, никогда не завершается.

Мы столкнулись с этой проблемой, когда в пуле соединений нашей базы данных knex постоянно заканчивались доступные соединения, после чего происходил сбой сервиса. Обычно в рамках соединения выполняется запрос, после чего оно возвращается в пул и может быть использовано для выполнения другого запроса.

Эти соединения что-то захватывало.

Речь идёт о кодовой базе в миллионы строк кода, которой в течение нескольких лет занимались десятки программистов. Может — проблема заключается в неразрешённых промисах? Я решил исследовать этот вопрос.

Проблема останова поднимает голову

Поиск неразрешённых промисов — это пример попытки решения проблемы останова, а известно, что не существует общего алгоритма решения этой проблемы.

Нет такого алгоритма, реализация которого может проанализировать фрагмент кода и ответить на вопрос о том, всегда ли, при любых входных данных, этот участок кода завершает работу. Провести такой анализ не получится и вручную.

Google выдал мне несколько страниц, где обсуждают неразрешённые промисы. Эти обсуждения всегда сводятся к тому, что не надо писать изначально некачественный код.

Типичное решение проблемы останова заключается в том, чтобы добавить в систему временные ограничения. Если функция не завершает работу в пределах N секунд — мы считаем, что она где-то застопорилась. Может, это и не так, но мы решаем, что это так, и «убиваем» программу.

Именно поэтому и существуют тайм-ауты соединений. Если сервер остановился — мы не собираемся ждать его вечно. Это важно при разработке распределённых систем.

Но «убийство» процесса сервера при каждом недоразумении — это решение не идеальное. И, кроме того, оснащение каждого промиса в кодовой базе тайм-аутом — это, в лучшем случае, очень сложно.

Но не так всё плохо! Проблему останова можно решить для подмножества распространённых паттернов.

Паттерны проблемных промисов

В прочитанной мной публикации «Нахождение проблемных промисов в асинхронных JavaScript-программах» Алимадади с соавторами выделили распространённые паттерны, которые приводят к появлению неразрешённых промисов, и представили программу PromiseKeeper. Эта программа находит потенциально неразрешаемые промисы с использованием графа промисов.

▍Краткий рассказ о JavaScript-промисах

Та публикация начинается с обзора JavaScript-промисов.

Промисы представляют асинхронные вычисления и могут пребывать в трёх состояниях: pending (ожидание), fulfilled (успешное разрешение) и rejected (отклонение). Вначале они оказываются в состоянии pending .

Код, реагирующий на результат работы промиса (обработчик определённого события), регистрируют с помощью метода .then() .

В коде, на практике, опускают второй параметр для того чтобы сосредоточиться на коде, который выполняется при успешном разрешении промиса ( fulfilledReaction ). Обычно так поступают при построении цепочек промисов:

Каждый вызов .then() приводит к созданию нового промиса, который разрешается возвращаемым значением кода, реагирующего на завершение работы предыдущего промиса. Обратите внимание на то, что последний вызов неявно разрешается со значением undefined . Дело в том, что в JavaScript функция, которая не возвращает что-либо, неявным образом возвращает undefined .

В цепочку промисов можно добавить механизм обработки ошибок с использованием .catch() :

Каждый промис, созданный .then() , неявно определяет код, реагирующий на отклонение промиса, аналогичный конструкции err => throw err . Это значит, что .catch() в конце цепочки промисов может отреагировать на ошибки, возникшие в любом из предыдущих промисов.

На практике редко полагаются на стандартный механизм обработки успешно разрешённых промисов, но следующий код корректен:

Полагаю, подобное чаще происходит случайно, чем намеренно.

Промисы можно связывать, используя один промис для разрешения другого промиса:

Здесь состояние промиса p0 связано с p1 . То есть — неименованный промис, созданный в строке 3, отклоняется со значением foo .

В реальном коде можно видеть много подобных конструкций. Часто они устроены не так понятно, как эти.

▍Паттерн №1: необработанное отклонение промиса

Обычным источником ошибок при работе с промисами являются необработанные отклонения промисов.

Это происходит, когда неявно отклоняют промис, выдавая ошибку в коде, реагирующем на успешное завершение промиса:

Так как код, реагирующий на успешное завершение промиса, выполняется в отдельном асинхронном контексте, JavaScript не передаёт эту ошибку в главный поток. Ошибка «проглатывается» и разработчик никогда не узнает о том, что она произошла.

Исправить это можно, использовав метод .catch() :

Теперь у нас появляется возможность обработать ошибку.

Но мы не перевыбросили эту ошибку! Если другой промис, связанный с этим, или объединённый с ним в цепочку, полагается на этот код, ошибка будет оставаться «проглоченной». Код продолжит выполняться.

Попробуйте следующее в консоли браузера:

Можно ожидать, что в этом коде выполняются вычисления 17 + 1 = 18 , но, из-за неожиданной ошибки, мы получаем NaN . Промис, неявно созданный .catch() , неявно разрешается (а не отклоняется) со значением undefined .

Это, конечно, примитивный пример, но представьте, как часто встречается этот паттерн в постоянно увеличивающейся кодовой базе, где каждая функция может, по какой угодно причине, выбросить ошибку.

▍Паттерн №2: незавершённые промисы

Новые промисы пребывают в состоянии pending до тех пор, пока не будут успешно разрешены или отклонены (то есть — завершены). Но если промис не завершается, его можно назвать остановившимся промисом. Он навсегда останется в состоянии pending , не давая выполняться коду, полагающемуся на его завершение.

Речь идёт о незавершённых промисах, которые крайне сложно обнаружить. Извне нельзя узнать о том, остановился ли промис, или он просто медленно работает.

Авторы вышеупомянутой публикации показывают пример проблемы из node-promise-mysql, где connection.release() возвращает промис, который никогда не разрешается.

Этот пример сложно свести к нескольким строкам кода, поэтому вот — кое-что попроще:

Последний промис соединён цепочкой из .then() с промисом p0 , который никогда не разрешается и не отклоняется. Этот код может выполняться вечно, но он никогда не выведет никакого значения.

Это, опять же, простейший пример, но представьте себе огромную кодовую базу, над которой работают десятки программистов. Совсем неочевидным может быть то, что функция в некоторых случаях бесконечно долго держит некий промис в состоянии pending .

▍Паттерн №3: неявные возвраты и код, реагирующий на результаты работы промиса

Цепочка из промисов прерывается без выдачи каких-либо ошибок в том случае, если разработчик забывает о включении в код выражения return .

Эта проблема похожа на ту, связанную с «проглатыванием» ошибок, о которой я уже рассказывал. Вот фрагмент кода из Google Assistant, который приводят Алимадади с соавторами:

Метод handleRequest() использует объект Map с обработчиками, предоставленными разработчиком, для организации асинхронной работы с запросами Assistant. Объект handler (обработчик) может быть либо коллбэком, либо промисом.

Если промис разрешается и вызывает предоставленный ему программистом анонимный обработчик, код возвращает результат. Если промис оказывается отклонённым — код возвращает причину этого.

Но все эти возвраты выполняются внутри кода, реагирующего на разрешение или отклонение промиса. Промис не осуществляет возврата значения. Результат реакции на промис handler теряется.

Пользователь этой библиотеки не может обработать результат разрешения или отклонения промисов, возвращённых его собственными обработчиками.

Поиск антипаттернов с помощью графа промисов

Алимадади с соавторами создали программу PromiseKeeper, которая динамически анализирует кодовую базу на JavaScript и рисует графы промисов.

Граф промисов

Мне не удалось запустить эту программу, поэтому передам то, о чём рассказали авторы публикации.

▍Графы промисов

Асинхронный код можно представить в виде графа, вершины которого (промисы, функции, значения, механизмы синхронизации) соединены рёбрами (разрешение промиса, регистрация обработчиков, связь, return или throw ).

• Вершины-промисы (p) представляют собой случаи запуска промисов.
• Вершины-значения (v) представляют значения, с которыми разрешаются или отклоняются промисы. Это могут быть функции.
• Вершины-функции (f) — это функции, зарегистрированные для обработки разрешения или отклонения промиса.
• Вершины-механизмы синхронизации (s) представляют собой все использованные в коде вызовы Promise.all() или Promise.race() .
• Рёбра разрешения или отклонения промиса (v)->(p) указывают на связи вершин-значений с вершинами-промисами. Они помечены как resolve или reject .
• Рёбра регистрации обработчиков (p)->(f) указывают на связи между промисом и функцией. Они помечены как onResolve или onReject .
• Рёбра связей (p1)->(p2) показывают взаимоотношения между связанными промисами.
• Рёбра return или throw (f)->(v) показывают связи функций и значений. Они помечены как return или throw .
• Рёбра механизмов синхронизации указывают на связи, идущие от множества промисов к одному механизму синхронизации промисов. Они помечаются как resolved , rejected или pending на основании того, как ведёт себя новый промис.

Аннотированный граф промисов

▍Использование PromiseKeeper для поиска анти-паттернов

Программа PromiseKeeper направлена на конструирование и визуализацию графа промисов кода. Она анализирует код динамически, по мере выполнения тестов. Динамический контекст выполнения кода позволяет находить анти-паттерны, которые не видны при анализе самого кода.

Вот на какие анти-паттерны обращает внимание программа:

• Пропущенные обработчики отклонения промисов — это ведёт к «проглатыванию» ошибок.
• Попытки многократного завершения работы промисов — это происходит, когда пытаются разрешить или отклонить промис, работа которого уже была завершена.
• Незавершённые промисы, то есть такие, которые не разрешены, но и не отклонены в то время, когда PromiseKeeper строит граф.
• Недостижимые обработчики — то есть код, зарегистрированный для обработки разрешения или отклонения промисов, который не выполняется во время динамического анализа кода, выполняемого PromiseKeeper.
• Неявные возвраты и стандартные обработчики — это может привести к неожиданному поведению промисов, расположенных ниже в цепочке промисов.
• Ненужные промисы — когда намеренно создают новый промис в функции, которая уже обёрнута в промис.

Реализация PromiseKeeper основана на фреймворке для динамического анализа JavaScript-кода Jalangi. В нём имеются коллбэки, которые реагируют на события жизненного цикла промисов.

Мне не удалось заставить работать PromiseKeeper на моём компьютере, но Алимадади с соавторами сообщают о том, что не вполне благополучные промисы встречаются почти во всех кодовых базах, в которых используется JavaScript.

Отчёт по выявленным анти-паттернам

Интересно то, что 1012 экземпляров незавершённых промисов встречаются всего в 17 местах кода Node Fetch.

Авторы сообщили, что в ходе их эксперимента 43% промисов оказались неразрешёнными. Это, вероятнее всего, указывает на неполноту тестов, а не на то, что популярные программные продукты, которые они исследовали, безнадёжно «поломаны».

Что делать?

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

Мы, решая проблемы промисов, добились серьёзных успехов, логируя сведения о необработанных отклонениях промисов, снабжённые полной трассировкой стека. Делается это с помощью такого кода:

Ещё можно попробовать Node.js-модуль async_hooks, который позволяет наблюдать за жизненным циклом промисов, и попытаться выявлять промисы, которые выполняются слишком долго. Можно, например, сравнивать время работы промиса с заданным тайм-аутом и выводить в консоль предупреждение.

У меня была интересная попытка использования async_hooks для выявления промисов, выполняющихся слишком долго, но особого толку из этого не вышло. Нельзя получить ссылку на контекст выполнения (только — C-указатель). То есть — можно увидеть, что что-то работает медленно, но о том, что это такое, узнать нельзя.

Меня привлекает идея превращения PromiseKeeper в нечто вроде плагина для Jest. Представьте себе, что после каждого запуска тестов формируется граф промисов, вроде того, который вы здесь видели.

Сталкивались ли вы с проблемами, вызванными неправильной работой промисов?

Js почему вс код подчеркивает необработанный промис

Promise chains are great at error handling. When a promise rejects, the control jumps to the closest rejection handler. That’s very convenient in practice.

For instance, in the code below the URL to fetch is wrong (no such site) and .catch handles the error:

As you can see, the .catch doesn’t have to be immediate. It may appear after one or maybe several .then .

Or, maybe, everything is all right with the site, but the response is not valid JSON. The easiest way to catch all errors is to append .catch to the end of chain:

Normally, such .catch doesn’t trigger at all. But if any of the promises above rejects (a network problem or invalid json or whatever), then it would catch it.

Implicit try…catch

The code of a promise executor and promise handlers has an "invisible try..catch " around it. If an exception happens, it gets caught and treated as a rejection.

For instance, this code:

…Works exactly the same as this:

The "invisible try..catch " around the executor automatically catches the error and turns it into rejected promise.

This happens not only in the executor function, but in its handlers as well. If we throw inside a .then handler, that means a rejected promise, so the control jumps to the nearest error handler.

Here’s an example:

This happens for all errors, not just those caused by the throw statement. For example, a programming error:

The final .catch not only catches explicit rejections, but also accidental errors in the handlers above.

Rethrowing

As we already noticed, .catch at the end of the chain is similar to try..catch . We may have as many .then handlers as we want, and then use a single .catch at the end to handle errors in all of them.

In a regular try..catch we can analyze the error and maybe rethrow it if it can’t be handled. The same thing is possible for promises.

If we throw inside .catch , then the control goes to the next closest error handler. And if we handle the error and finish normally, then it continues to the next closest successful .then handler.

In the example below the .catch successfully handles the error:

Here the .catch block finishes normally. So the next successful .then handler is called.

In the example below we see the other situation with .catch . The handler (*) catches the error and just can’t handle it (e.g. it only knows how to handle URIError ), so it throws it again:

The execution jumps from the first .catch (*) to the next one (**) down the chain.

Unhandled rejections

What happens when an error is not handled? For instance, we forgot to append .catch to the end of the chain, like here:

In case of an error, the promise becomes rejected, and the execution should jump to the closest rejection handler. But there is none. So the error gets “stuck”. There’s no code to handle it.

In practice, just like with regular unhandled errors in code, it means that something has gone terribly wrong.

What happens when a regular error occurs and is not caught by try..catch ? The script dies with a message in the console. A similar thing happens with unhandled promise rejections.

The JavaScript engine tracks such rejections and generates a global error in that case. You can see it in the console if you run the example above.

In the browser we can catch such errors using the event unhandledrejection :

The event is the part of the HTML standard.

If an error occurs, and there’s no .catch , the unhandledrejection handler triggers, and gets the event object with the information about the error, so we can do something.

Usually such errors are unrecoverable, so our best way out is to inform the user about the problem and probably report the incident to the server.

Поиск проблемных промисов в JavaScript

JavaScript — это фантастический язык для серверного программирования, так как он поддерживает асинхронное выполнение кода. Но это ещё и усложняет его использование.

Асинхронность означает возможность написания кода, который не подвержен обычным проблемам, связанным с потокобезопасностью, и поддерживает выполнение множества задач в «параллельном» режиме. Например — ожидание считывания файла не блокирует другие вычисления.

Но небольшие ошибки в асинхронном коде могут приводить к появлению неразрешённых промисов. То есть — к участкам кода, выполнение которых, однажды начавшись, никогда не завершается.

Мы столкнулись с этой проблемой, когда в пуле соединений нашей базы данных knex постоянно заканчивались доступные соединения, после чего происходил сбой сервиса. Обычно в рамках соединения выполняется запрос, после чего оно возвращается в пул и может быть использовано для выполнения другого запроса.

Эти соединения что-то захватывало.

Речь идёт о кодовой базе в миллионы строк кода, которой в течение нескольких лет занимались десятки программистов. Может — проблема заключается в неразрешённых промисах? Я решил исследовать этот вопрос.

Проблема останова поднимает голову

Поиск неразрешённых промисов — это пример попытки решения проблемы останова, а известно, что не существует общего алгоритма решения этой проблемы.

Нет такого алгоритма, реализация которого может проанализировать фрагмент кода и ответить на вопрос о том, всегда ли, при любых входных данных, этот участок кода завершает работу. Провести такой анализ не получится и вручную.

Google выдал мне несколько страниц, где обсуждают неразрешённые промисы. Эти обсуждения всегда сводятся к тому, что не надо писать изначально некачественный код.

Типичное решение проблемы останова заключается в том, чтобы добавить в систему временные ограничения. Если функция не завершает работу в пределах N секунд — мы считаем, что она где-то застопорилась. Может, это и не так, но мы решаем, что это так, и «убиваем» программу.

Именно поэтому и существуют тайм-ауты соединений. Если сервер остановился — мы не собираемся ждать его вечно. Это важно при разработке распределённых систем.

Но «убийство» процесса сервера при каждом недоразумении — это решение не идеальное. И, кроме того, оснащение каждого промиса в кодовой базе тайм-аутом — это, в лучшем случае, очень сложно.

Но не так всё плохо! Проблему останова можно решить для подмножества распространённых паттернов.

Паттерны проблемных промисов

В прочитанной мной публикации «Нахождение проблемных промисов в асинхронных JavaScript-программах» Алимадади с соавторами выделили распространённые паттерны, которые приводят к появлению неразрешённых промисов, и представили программу PromiseKeeper. Эта программа находит потенциально неразрешаемые промисы с использованием графа промисов.

▍Краткий рассказ о JavaScript-промисах

Та публикация начинается с обзора JavaScript-промисов.

Промисы представляют асинхронные вычисления и могут пребывать в трёх состояниях: pending (ожидание), fulfilled (успешное разрешение) и rejected (отклонение). Вначале они оказываются в состоянии pending .

Код, реагирующий на результат работы промиса (обработчик определённого события), регистрируют с помощью метода .then() .

В коде, на практике, опускают второй параметр для того чтобы сосредоточиться на коде, который выполняется при успешном разрешении промиса ( fulfilledReaction ). Обычно так поступают при построении цепочек промисов:

Каждый вызов .then() приводит к созданию нового промиса, который разрешается возвращаемым значением кода, реагирующего на завершение работы предыдущего промиса. Обратите внимание на то, что последний вызов неявно разрешается со значением undefined . Дело в том, что в JavaScript функция, которая не возвращает что-либо, неявным образом возвращает undefined .

В цепочку промисов можно добавить механизм обработки ошибок с использованием .catch() :

Каждый промис, созданный .then() , неявно определяет код, реагирующий на отклонение промиса, аналогичный конструкции err => throw err . Это значит, что .catch() в конце цепочки промисов может отреагировать на ошибки, возникшие в любом из предыдущих промисов.

На практике редко полагаются на стандартный механизм обработки успешно разрешённых промисов, но следующий код корректен:

Полагаю, подобное чаще происходит случайно, чем намеренно.

Промисы можно связывать, используя один промис для разрешения другого промиса:

Здесь состояние промиса p0 связано с p1 . То есть — неименованный промис, созданный в строке 3, отклоняется со значением foo .

В реальном коде можно видеть много подобных конструкций. Часто они устроены не так понятно, как эти.

▍Паттерн №1: необработанное отклонение промиса

Обычным источником ошибок при работе с промисами являются необработанные отклонения промисов.

Это происходит, когда неявно отклоняют промис, выдавая ошибку в коде, реагирующем на успешное завершение промиса:

Так как код, реагирующий на успешное завершение промиса, выполняется в отдельном асинхронном контексте, JavaScript не передаёт эту ошибку в главный поток. Ошибка «проглатывается» и разработчик никогда не узнает о том, что она произошла.

Исправить это можно, использовав метод .catch() :

Теперь у нас появляется возможность обработать ошибку.

Но мы не перевыбросили эту ошибку! Если другой промис, связанный с этим, или объединённый с ним в цепочку, полагается на этот код, ошибка будет оставаться «проглоченной». Код продолжит выполняться.

Попробуйте следующее в консоли браузера:

Можно ожидать, что в этом коде выполняются вычисления 17 + 1 = 18 , но, из-за неожиданной ошибки, мы получаем NaN . Промис, неявно созданный .catch() , неявно разрешается (а не отклоняется) со значением undefined .

Это, конечно, примитивный пример, но представьте, как часто встречается этот паттерн в постоянно увеличивающейся кодовой базе, где каждая функция может, по какой угодно причине, выбросить ошибку.

▍Паттерн №2: незавершённые промисы

Новые промисы пребывают в состоянии pending до тех пор, пока не будут успешно разрешены или отклонены (то есть — завершены). Но если промис не завершается, его можно назвать остановившимся промисом. Он навсегда останется в состоянии pending , не давая выполняться коду, полагающемуся на его завершение.

Речь идёт о незавершённых промисах, которые крайне сложно обнаружить. Извне нельзя узнать о том, остановился ли промис, или он просто медленно работает.

Авторы вышеупомянутой публикации показывают пример проблемы из node-promise-mysql, где connection.release() возвращает промис, который никогда не разрешается.

Этот пример сложно свести к нескольким строкам кода, поэтому вот — кое-что попроще:

Последний промис соединён цепочкой из .then() с промисом p0 , который никогда не разрешается и не отклоняется. Этот код может выполняться вечно, но он никогда не выведет никакого значения.

Это, опять же, простейший пример, но представьте себе огромную кодовую базу, над которой работают десятки программистов. Совсем неочевидным может быть то, что функция в некоторых случаях бесконечно долго держит некий промис в состоянии pending .

▍Паттерн №3: неявные возвраты и код, реагирующий на результаты работы промиса

Цепочка из промисов прерывается без выдачи каких-либо ошибок в том случае, если разработчик забывает о включении в код выражения return .

Эта проблема похожа на ту, связанную с «проглатыванием» ошибок, о которой я уже рассказывал. Вот фрагмент кода из Google Assistant, который приводят Алимадади с соавторами:

Метод handleRequest() использует объект Map с обработчиками, предоставленными разработчиком, для организации асинхронной работы с запросами Assistant. Объект handler (обработчик) может быть либо коллбэком, либо промисом.

Если промис разрешается и вызывает предоставленный ему программистом анонимный обработчик, код возвращает результат. Если промис оказывается отклонённым — код возвращает причину этого.

Но все эти возвраты выполняются внутри кода, реагирующего на разрешение или отклонение промиса. Промис не осуществляет возврата значения. Результат реакции на промис handler теряется.

Пользователь этой библиотеки не может обработать результат разрешения или отклонения промисов, возвращённых его собственными обработчиками.

Поиск антипаттернов с помощью графа промисов

Алимадади с соавторами создали программу PromiseKeeper, которая динамически анализирует кодовую базу на JavaScript и рисует графы промисов.

Граф промисов

Мне не удалось запустить эту программу, поэтому передам то, о чём рассказали авторы публикации.

▍Графы промисов

Асинхронный код можно представить в виде графа, вершины которого (промисы, функции, значения, механизмы синхронизации) соединены рёбрами (разрешение промиса, регистрация обработчиков, связь, return или throw ).

• Вершины-промисы (p) представляют собой случаи запуска промисов.
• Вершины-значения (v) представляют значения, с которыми разрешаются или отклоняются промисы. Это могут быть функции.
• Вершины-функции (f) — это функции, зарегистрированные для обработки разрешения или отклонения промиса.
• Вершины-механизмы синхронизации (s) представляют собой все использованные в коде вызовы Promise.all() или Promise.race() .
• Рёбра разрешения или отклонения промиса (v)->(p) указывают на связи вершин-значений с вершинами-промисами. Они помечены как resolve или reject .
• Рёбра регистрации обработчиков (p)->(f) указывают на связи между промисом и функцией. Они помечены как onResolve или onReject .
• Рёбра связей (p1)->(p2) показывают взаимоотношения между связанными промисами.
• Рёбра return или throw (f)->(v) показывают связи функций и значений. Они помечены как return или throw .
• Рёбра механизмов синхронизации указывают на связи, идущие от множества промисов к одному механизму синхронизации промисов. Они помечаются как resolved , rejected или pending на основании того, как ведёт себя новый промис.

Аннотированный граф промисов

▍Использование PromiseKeeper для поиска анти-паттернов

Программа PromiseKeeper направлена на конструирование и визуализацию графа промисов кода. Она анализирует код динамически, по мере выполнения тестов. Динамический контекст выполнения кода позволяет находить анти-паттерны, которые не видны при анализе самого кода.

Вот на какие анти-паттерны обращает внимание программа:

• Пропущенные обработчики отклонения промисов — это ведёт к «проглатыванию» ошибок.
• Попытки многократного завершения работы промисов — это происходит, когда пытаются разрешить или отклонить промис, работа которого уже была завершена.
• Незавершённые промисы, то есть такие, которые не разрешены, но и не отклонены в то время, когда PromiseKeeper строит граф.
• Недостижимые обработчики — то есть код, зарегистрированный для обработки разрешения или отклонения промисов, который не выполняется во время динамического анализа кода, выполняемого PromiseKeeper.
• Неявные возвраты и стандартные обработчики — это может привести к неожиданному поведению промисов, расположенных ниже в цепочке промисов.
• Ненужные промисы — когда намеренно создают новый промис в функции, которая уже обёрнута в промис.

Реализация PromiseKeeper основана на фреймворке для динамического анализа JavaScript-кода Jalangi. В нём имеются коллбэки, которые реагируют на события жизненного цикла промисов.

Мне не удалось заставить работать PromiseKeeper на моём компьютере, но Алимадади с соавторами сообщают о том, что не вполне благополучные промисы встречаются почти во всех кодовых базах, в которых используется JavaScript.

Отчёт по выявленным анти-паттернам

Интересно то, что 1012 экземпляров незавершённых промисов встречаются всего в 17 местах кода Node Fetch.

Авторы сообщили, что в ходе их эксперимента 43% промисов оказались неразрешёнными. Это, вероятнее всего, указывает на неполноту тестов, а не на то, что популярные программные продукты, которые они исследовали, безнадёжно «поломаны».

Что делать?

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

Мы, решая проблемы промисов, добились серьёзных успехов, логируя сведения о необработанных отклонениях промисов, снабжённые полной трассировкой стека. Делается это с помощью такого кода:

Ещё можно попробовать Node.js-модуль async_hooks, который позволяет наблюдать за жизненным циклом промисов, и попытаться выявлять промисы, которые выполняются слишком долго. Можно, например, сравнивать время работы промиса с заданным тайм-аутом и выводить в консоль предупреждение.

У меня была интересная попытка использования async_hooks для выявления промисов, выполняющихся слишком долго, но особого толку из этого не вышло. Нельзя получить ссылку на контекст выполнения (только — C-указатель). То есть — можно увидеть, что что-то работает медленно, но о том, что это такое, узнать нельзя.

Меня привлекает идея превращения PromiseKeeper в нечто вроде плагина для Jest. Представьте себе, что после каждого запуска тестов формируется граф промисов, вроде того, который вы здесь видели.

Сталкивались ли вы с проблемами, вызванными неправильной работой промисов?

Промисы: обработка ошибок

Цепочки промисов отлично подходят для перехвата ошибок. Если промис завершается с ошибкой, то управление переходит в ближайший обработчик ошибок. На практике это очень удобно.

Например, в представленном ниже примере для fetch указана неправильная ссылка (сайт не существует), и .catch перехватывает ошибку:

Как видно, .catch не обязательно должен быть сразу после ошибки, он может быть далее, после одного или даже нескольких .then

Или, может быть, с сервером всё в порядке, но в ответе мы получим некорректный JSON. Самый лёгкий путь перехватить все ошибки – это добавить .catch в конец цепочки:

Если все в порядке, то такой .catch вообще не выполнится. Но если любой из промисов будет отклонён (проблемы с сетью или некорректная json-строка, или что угодно другое), то ошибка будет перехвачена.

Неявный try…catch

Вокруг функции промиса и обработчиков находится "невидимый try..catch ". Если происходит исключение, то оно перехватывается, и промис считается отклонённым с этой ошибкой.

Например, этот код:

…Работает так же, как и этот:

"Невидимый try..catch " вокруг промиса автоматически перехватывает ошибку и превращает её в отклонённый промис.

Это работает не только в функции промиса, но и в обработчиках. Если мы бросим ошибку ( throw ) из обработчика ( .then ), то промис будет считаться отклонённым, и управление перейдёт к ближайшему обработчику ошибок.

Это происходит для всех ошибок, не только для тех, которые вызваны оператором throw . Например, программная ошибка:

Финальный .catch перехватывает как промисы, в которых вызван reject , так и случайные ошибки в обработчиках.

Пробрасывание ошибок

Как мы уже заметили, .catch ведёт себя как try..catch . Мы можем иметь столько обработчиков .then , сколько мы хотим, и затем использовать один .catch в конце, чтобы перехватить ошибки из всех обработчиков.

В обычном try..catch мы можем проанализировать ошибку и повторно пробросить дальше, если не можем её обработать. То же самое возможно для промисов.

Если мы пробросим ( throw ) ошибку внутри блока .catch , то управление перейдёт к следующему ближайшему обработчику ошибок. А если мы обработаем ошибку и завершим работу обработчика нормально, то продолжит работу ближайший успешный обработчик .then .

В примере ниже .catch успешно обрабатывает ошибку:

Здесь блок .catch завершается нормально. Поэтому вызывается следующий успешный обработчик .then .

В примере ниже мы видим другую ситуацию с блоком .catch . Обработчик (*) перехватывает ошибку и не может обработать её (например, он знает как обработать только URIError ), поэтому ошибка пробрасывается далее:

Управление переходит от первого блока .catch (*) к следующему (**) , вниз по цепочке.

Необработанные ошибки

Что произойдёт, если ошибка не будет обработана? Например, мы просто забыли добавить .catch в конец цепочки, как здесь:

В случае ошибки выполнение должно перейти к ближайшему обработчику ошибок. Но в примере выше нет никакого обработчика. Поэтому ошибка как бы «застревает», её некому обработать.

На практике, как и при обычных необработанных ошибках в коде, это означает, что что-то пошло сильно не так.

Что происходит, когда обычная ошибка не перехвачена try..catch ? Скрипт умирает с сообщением в консоли. Похожее происходит и в случае необработанной ошибки промиса.

JavaScript-движок отслеживает такие ситуации и генерирует в этом случае глобальную ошибку. Вы можете увидеть её в консоли, если запустите пример выше.

В браузере мы можем поймать такие ошибки, используя событие unhandledrejection :

Это событие является частью стандарта HTML.

Если происходит ошибка, и отсутствует её обработчик, то генерируется событие unhandledrejection , и соответствующий объект event содержит информацию об ошибке.

Обычно такие ошибки неустранимы, поэтому лучше всего – информировать пользователя о проблеме и, возможно, отправить информацию об ошибке на сервер.

Подробное руководство по обработке ошибок в Node.js

Если вы писали что-то большее, чем программы «Hello world», вы, вероятно, знакомы с концепцией ошибок в программировании. Это ошибки в вашем коде, часто называемые «bugs», которые приводят к сбою программы или неожиданному поведению. В отличие от некоторых языков, таких как Go и Rust, где вы вынуждены взаимодействовать с потенциальными ошибками на каждом этапе пути, в JavaScript и Node.js можно обойтись без согласованной стратегии обработки ошибок.

Однако это не обязательно должно быть так, потому что обработка ошибок Node.js может быть довольно простой, если вы знакомы с шаблонами, используемыми для создания, доставки и обработки потенциальных ошибок. Эта статья призвана познакомить вас с этими шаблонами, чтобы вы могли сделать свои программы более надежными, гарантируя, что вы обнаружите потенциальные ошибки и обработаете их надлежащим образом, прежде чем развертывать свое приложение в рабочей среде!

Что такое ошибки в Node.js

Ошибка в Node.js — это любой экземпляр объекта Error . Типичные примеры включают встроенные классы ошибок, таких как ReferenceError , RangeError , TypeError , URIError , EvalError , и SyntaxError . Определяемые пользователем ошибки также можно создавать путем расширения базового объекта Error , встроенного класса ошибок или другой пользовательской ошибки. При создании ошибок таким образом вы должны передать строку сообщения, описывающую ошибку. Доступ к этому сообщению можно получить через свойство объекта message . Объект Error также содержит name в свойстве stack , указав имя ошибки и точки в коде, на котором он был создан, соответственно.

Получив объект Error , вы можете передать его функции или вернуть из функции. Вы также можете сделать throw , что приведет к тому, что объект Error станет исключением. Как только вы выдаете ошибку, она всплывает в стеке до тех пор, пока ее где-нибудь не поймают. Если вам не удастся еt поймать, онf станет неперехваченным исключением, которое может привести к сбою вашего приложения!

Как устранить ошибки

Подходящий способ устранения ошибок из функции JavaScript зависит от того, выполняет ли функция синхронную или асинхронную операцию. В этом разделе я подробно опишу четыре распространенных шаблона устранения ошибок из функции в приложении Node.js.

1. Исключения

Наиболее распространенный способ устранения ошибок функциями — их генерация. Когда вы выдаете ошибку, она становится исключением и должна быть перехвачена где-то в стеке с помощью блока try/catch . Если ошибка может всплывать в стеке без обнаружения, она становится uncaughtException , что приводит к преждевременному завершению работы приложения. Например, встроенный метод JSON.parse() выдает ошибку, если его строковый аргумент не является допустимым объектом JSON.

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

2. Обратные вызовы с ошибкой

Из-за своей асинхронной природы Node.js широко использует функции обратного вызова для большей части обработки ошибок. Функция обратного вызова передается в качестве аргумента другой функции и выполняется, когда функция завершает свою работу. Если вы какое-то время писали код JavaScript, вы, вероятно, знаете, что шаблон обратного вызова широко используется во всем коде JavaScript.

Node.js использует в большинстве своих асинхронных методов соглашение об обратном вызове «сначала ошибка», чтобы убедиться, что ошибки проверяются должным образом до того, как будут использованы результаты операции. Эта функция обратного вызова обычно является последним аргументом функции, инициирующей асинхронную операцию, и вызывается один раз при возникновении ошибки или при получении результата операции. Ее подпись показана ниже:

Первый аргумент зарезервирован для объекта ошибки. Если в ходе асинхронной операции возникает ошибка, она будет доступна через аргумент err и result будет иметь значение undefined. Однако, если ошибки не возникнет err будет null или undefined и result будет содержать ожидаемый результат операции. Этот шаблон можно продемонстрировать, прочитав содержимое файла с помощью встроенного метода fs.readFile() :

Как вы можете видеть метод readFile() ожидает функцию обратного вызова в качестве своего последнего аргумента, который придерживается описанной ранее сигнатуры функции «сначала ошибка». В этом сценарии аргумент result содержит содержимое прочитанного файла, если не возникает ошибки. В противном случае undefined и аргумент err заполняется объектом ошибки, содержащим информацию о проблеме (например, файл не найден или недостаточные разрешения).

Как правило, методы, которые используют этот шаблон обратного вызова для доставки ошибок, не могут знать, насколько важна ошибка, которую они производят, для вашего приложения. Это может быть серьезным или тривиальным. Вместо того, чтобы принимать решение самостоятельно, ошибка отправляется вам для обработки. Важно контролировать поток содержимого функции обратного вызова, всегда проверяя наличие ошибки перед попыткой доступа к результату операции. Игнорировать ошибки небезопасно, и вы не должны доверять содержимому result перед проверкой ошибок.

Если вы хотите использовать этот шаблон обратного вызова с первой ошибкой в ​​своих собственных асинхронных функциях, все, что вам нужно сделать, это принять функцию в качестве последнего аргумента и вызвать ее, как показано ниже:

Любому вызывающему объекту этой функции square потребуется передать функцию обратного вызова, чтобы получить доступ к ее результату или ошибке. Обратите внимание, что во время выполнения возникает исключение, если аргумент обратного вызова не является функцией.

Вам не нужно напрямую обрабатывать ошибку в функции обратного вызова. Вы можете распространить его вверх по стеку, передав его другому обратному вызову, но не генерируйте исключение из функции, потому что оно не будет перехвачено, даже если вы окружите код блоком try/catch . Асинхронное исключение невозможно перехватить, поскольку окружающий блок try/catch завершается до выполнения обратного вызова. Таким образом, исключение будет распространяться на вершину стека, вызывая сбой приложения, если для него не зарегистрирован обработчик process.on(‘uncaughtException’) , который будет обсуждаться позже.

3. Отказ от промисов

Промисы — это современный способ выполнения асинхронных операций в Node.js, и в настоящее время они обычно предпочтительнее обратных вызовов, потому что этот подход имеет лучший поток, который соответствует тому, как мы анализируем программы, особенно с шаблоном async/await . Любой API-интерфейс Node.js, который использует обратные вызовы для асинхронной обработки ошибок, может быть преобразован в промисы с помощью встроенного метода util.promisify() . Например, вот как можно использовать метод fs.ReadFile() для использования промисов:

Переменная ReadFile — это обещанная версия fs.ReadFile() , в которой отклонения промисов используются для сообщения об ошибках. Эти ошибки могут быть обнаружены с помощью метода цепочки catch , как показано ниже:

Вы также можете использовать обещанные API в функции async , такой как показанна ниже. Это преобладающий способ использования обещаний в современном JavaScript, потому что код читается как синхронный код, а для обработки ошибок можно использовать знакомый механизм try/catch . Важно использовать await перед асинхронным методом, чтобы промис был выполнен (выполнен или отклонен) до того, как функция возобновит свое выполнение. Если промис отклоняется, выражение await выдает отклоненное значение, которое впоследствии перехватывается в окружающем блоке catch

Вы можете использовать промисы в своих асинхронных функциях, возвращая промис из функции и помещая код функции в обратный вызов промиса. Если есть ошибка, reject с объектом Error . В противном случае resolve промис с результатом, чтобы оно было доступно в цепочке метода .then или непосредственно в качестве значения функции async при использовании async/await .

4. Генераторы событий

Другой шаблон, который можно использовать при работе с длительными асинхронными операциями, которые могут привести к множеству ошибок или результатов, заключается в возврате EventEmitter из функции и создании события как в случае успеха, так и в случае неудачи. Пример этого кода показан ниже:

Функция emitCount() возвращает новый источник событий, который сообщает как об успехе, так и о сбое в асинхронной операции. Функция увеличивает переменную count и генерирует событие success каждую секунду, а также событие error , если count делится на 4 . Когда count достигает 10, генерируется событие end . Этот шаблон позволяет выполнять потоковую передачу результатов по мере их поступления, а не ждать завершения всей операции.

Вот как вы можете обрабатывать и реагировать на каждое из событий, исходящих от функции emitCount() :

Как вы можете видеть на изображении выше, функция обратного вызова для каждого обработчика событий выполняется независимо, как только событие генерируется. Событие error является особым случаем в Node.js, потому что, если для него нет обработчика, процесс Node.js завершится сбоем. Вы можете закомментировать обработчик событий error выше и запустить программу, чтобы посмотреть, что произойдет.

Расширение объекта ошибки

Использование встроенных классов ошибок или универсального экземпляра объекта Error обычно недостаточно точно для сообщения всех различных типов ошибок. Поэтому необходимо создавать пользовательские классы ошибок, чтобы лучше отражать типы ошибок, которые могут возникнуть в вашем приложении. Например, у вас может быть класс ValidationError для ошибок, возникающих при проверке пользовательского ввода, DatabaseError для операций с базой данных, класс TimeoutError для операций, для которых истекают назначенные им тайм-ауты, и так далее.

Пользовательские классы ошибок, расширяющие объект ошибки, сохранят основные свойства ошибки, такие как message , name , и stack , но они также могут иметь собственные свойства. Например ValidationError можно улучшить, добавив значимые свойства, такие как часть ввода, вызвавшую ошибку. По сути, вы должны включить достаточно информации, чтобы обработчик ошибок правильно обработал ошибку или создал свои собственные сообщения об ошибках.

Вот как расширить встроенный объект Error в Node.js:

Приведенный выше класс ApplicationError является общей ошибкой для приложения, а класс ValidationError представляет любую ошибку, возникающую при проверке пользовательского ввода. Он наследуется от класса ApplicationError и дополняет его свойством cause , чтобы указать ввод, вызвавший ошибку. Вы можете использовать пользовательские ошибки в своем коде так же, как и с обычной ошибкой. Например, вы можете throw :

Ключевое слово instanceof следует использовать для проверки определенного типа ошибок, как показано выше. Не используйте имя ошибки для проверки типа, как в err.name === ‘ValidationError’ , потому что это не сработает, если ошибка получена из подкласса ValidationError .

Типы ошибок

Полезно различать разные типы ошибок, которые могут возникнуть в приложении Node.js. Как правило, ошибки можно разделить на две основные категории: ошибки программиста и операционные проблемы. Плохие или неверные аргументы функции — это пример проблем первого типа, тогда как временные сбои при работе с внешними API относятся ко второй категории.

1. Операционные ошибки

Операционные ошибки — это в основном ожидаемые ошибки, которые могут возникнуть в процессе выполнения приложения. Это не обязательно ошибки, но внешние обстоятельства, которые могут нарушить ход выполнения программы. В таких случаях все последствия ошибки можно понять и соответствующим образом обработать. Некоторые примеры операционных ошибок в Node.js включают следующее:

1. Запрос API завершается ошибкой по какой-либо причине (например, сервер не работает или превышен лимит скорости).
2. Соединение с базой данных потеряно, возможно, из-за неисправного сетевого соединения.
3. ОС не может выполнить ваш запрос на открытие файла или запись в него.
4. Пользователь отправляет на сервер неверный ввод, например неверный номер телефона или адрес электронной почты.

Эти ситуации не возникают из-за ошибок в коде приложения, но с ними нужно правильно обращаться. В противном случае они могут вызвать более серьезные проблемы.

2. Ошибки программиста

Ошибки программиста — это ошибки в логике или синтаксисе программы, которые можно исправить только путем изменения исходного кода. Эти типы ошибок не могут быть обработаны, потому что по определению они являются ошибками в программе. Вот некоторые примеры ошибок программиста:

1. Синтаксические ошибки, такие как невозможность закрыть фигурную скобку.
2. Ошибки типа, когда вы пытаетесь сделать что-то недопустимое, например, выполнять операции с операндами несовпадающих типов.
3. Неверные параметры при вызове функции.
4. Ссылочные ошибки при неправильном написании имени переменной, функции или свойства.
5. Попытка доступа к местоположению за концом массива.
6. Не удалось обработать операционную ошибку.

Оперативная обработка ошибок

Операционные ошибки в основном предсказуемы, поэтому их необходимо предвидеть и учитывать в процессе разработки. По сути, обработка этих типов ошибок включает в себя рассмотрение того, может ли операция завершиться неудачно, почему она может завершиться неудачно и что должно произойти, если это произойдет. Рассмотрим несколько стратегий обработки операционных ошибок в Node.js.

1. Сообщите об ошибке вверх по стеку

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

2. Повторите операцию

Сетевые запросы к внешним службам иногда могут завершаться ошибкой, даже если запрос полностью действителен. Это может быть связано с временным сбоем, который может возникнуть при сбое сети или перегрузке сервера. Такие проблемы обычно непродолжительны, поэтому вместо того, чтобы немедленно сообщать об ошибке, вы можете повторить запрос несколько раз, пока он не будет успешным или пока не будет достигнуто максимальное количество повторных попыток. Первое соображение заключается в том, чтобы определить, уместно ли повторить запрос. Например, если исходный код состояния HTTP-ответа — 500, 503 или 429, может оказаться целесообразным повторить запрос после небольшой задержки.

Вы можете проверить, присутствует ли в ответе HTTP-заголовок Retry-After. В этом заголовке указывается точное время ожидания перед выполнением последующего запроса. Если заголовок Retry-After не существует, вам необходимо отложить последующий запрос и постепенно увеличивать задержку для каждой последующей повторной попытки. Это известно как экспоненциальная стратегия отсрочки. Вам также необходимо определить максимальный интервал задержки и количество повторных попыток запроса, прежде чем отказаться от него. В этот момент вы должны сообщить вызывающему абоненту, что целевая служба недоступна.

3. Отправить ошибку клиенту

Имея дело с внешним вводом от пользователей, следует исходить из того, что ввод неверен по умолчанию. Поэтому первое, что нужно сделать перед запуском каких-либо процессов, — это проверить ввод и незамедлительно сообщить пользователю о любых ошибках, чтобы его можно было исправить и повторно отправить. При доставке ошибок клиента не забудьте включить всю информацию, необходимую клиенту для создания сообщения об ошибке, понятного пользователю.

4. Прервать программу

В случае неисправимых системных ошибок единственным разумным действием является регистрация ошибки и немедленное завершение программы. Возможно, вы даже не сможете корректно завершить работу сервера, если исключение невозможно восстановить на уровне JavaScript. В этот момент от системного администратора может потребоваться изучить проблему и исправить ее, прежде чем программа сможет снова запуститься.

Предотвращение ошибок программиста

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

1. Примите TypeScript

TypeScript — является строго типизированным надмножеством JavaScript. Его основная цель разработки — статическая идентификация конструкций, которые могут быть ошибочными, без каких-либо штрафов во время выполнения. Приняв TypeScript в свой проект (с максимально строгими параметрами компилятора), вы сможете устранить целый класс ошибок программиста во время компиляции. Например, после проведения постфактум-анализа ошибок было подсчитано, что 38% ошибок в кодовой базе Airbnb можно было предотвратить с помощью TypeScript.

Когда вы переносите весь свой проект на TypeScript, такие ошибки, как « undefined is not a function», синтаксические ошибки или ошибки ссылок, больше не должны существовать в вашей кодовой базе. К счастью, это не так страшно, как кажется. Миграция всего вашего приложения Node.js на TypeScript может выполняться поэтапно, чтобы вы могли сразу же начать пожинать плоды в важнейших частях кодовой базы. Вы также можете использовать такой инструмент, как ts-migrate, если вы собираетесь выполнить миграцию за один раз.

2. Определите поведение для неверных параметров

Многие ошибки программиста возникают из-за передачи неправильных параметров. Это может быть связано не только с очевидными ошибками, такими как передача строки вместо числа, но и с тонкими ошибками, например, когда аргумент функции имеет правильный тип, но выходит за пределы того, что может обработать функция. Когда программа запущена и функция вызывается таким образом, она может незаметно завершиться ошибкой и выдать неправильное значение, например NaN . Когда сбой в конце концов заметен (обычно после прохождения через несколько других функций), может быть трудно определить его причины.

Вы можете справиться с неправильными параметрами, определив их поведение, выдав ошибку или вернув специальное значение, такое как null , undefined , или -1 , когда проблема может быть решена локально. Первый — это подход, используемый JSON.parse() , который генерирует исключение SyntaxError , если строка для синтаксического анализа не является допустимой JSON, тогда как метод string.indexOf() является примером последнего. Что бы вы ни выбрали, обязательно задокументируйте, как функция обрабатывает ошибки, чтобы вызывающая сторона знала, чего ожидать.

3. Автоматизированное тестирование

Сам по себе язык JavaScript мало помогает вам найти ошибки в логике вашей программы, поэтому вам нужно запустить программу, чтобы определить, работает ли она должным образом. Наличие набора автоматизированных тестов повышает вероятность того, что вы обнаружите и исправите различные ошибки программиста, особенно логические. Они также помогают выяснить, как функция работает с нетипичными значениями. Использование среды тестирования, такой как Jest или Mocha, — хороший способ начать модульное тестирование приложений Node.js.

Неперехваченные исключения и необработанные отказы от промисов

Неперехваченные исключения и необработанные отклонения промисов вызваны ошибками программиста, возникающими из-за невозможности перехватить сгенерированное исключение и отклонение промисов соответственно. Событие uncaughtException возникает, когда исключение, созданное где-либо в приложении, не перехвачено до того, как оно достигнет цикла событий. Если обнаружено неперехваченное исключение, приложение немедленно выйдет из строя, но вы можете добавить обработчик этого события, чтобы переопределить это поведение. Действительно, многие люди используют это как крайний способ поглотить ошибку, чтобы приложение могло продолжать работать, как будто ничего не произошло:

Однако это неправильное использование этого события, поскольку наличие необработанного исключения указывает на то, что приложение находится в неопределенном состоянии. Таким образом, попытка нормального возобновления работы без восстановления после ошибки считается небезопасной и может привести к дальнейшим проблемам, таким как утечка памяти и зависание сокетов. Надлежащее использование обработчика uncaughtException заключается в очистке всех выделенных ресурсов, закрытии соединений и регистрации ошибки для последующей оценки перед выходом из процесса.

Точно так же событие unhandledRejection генерируется, когда отклоненное обещание не обрабатывается блоком catch . В отличие от uncaughtException , эти события не вызывают немедленного сбоя приложения. Однако необработанные отказы от промисов устарели и могут немедленно прервать процесс в будущем выпуске Node.js. Вы можете отслеживать необработанные отказы обещаний через обработчик событий unhandledRejection , как показано ниже:

Вы всегда должны запускать свои серверы с помощью диспетчера процессов, который автоматически перезапустит их в случае сбоя. Распространенным является PM2, но у вас также есть systemd или upstart в Linux, и пользователи Docker могут использовать его политику перезапуска. Как только это будет сделано, надежный сервис будет восстановлен почти мгновенно, и вы по-прежнему будете иметь сведения о неперехваченном исключении, чтобы его можно было быстро исследовать и исправить. Вы можете пойти дальше, запустив более одного процесса и используя балансировщик нагрузки для распределения входящих запросов. Это поможет предотвратить простои в случае временной потери одного из экземпляров.

Централизованная отчетность об ошибках

Ни одна стратегия обработки ошибок не будет полной без надежной стратегии ведения журнала для вашего работающего приложения. Когда происходит сбой, важно выяснить, почему он произошел, записав как можно больше информации о проблеме. Централизация этих журналов позволяет легко получить полную информацию о вашем приложении. Вы сможете сортировать и фильтровать свои ошибки, просматривать основные проблемы и подписываться на оповещения, чтобы получать уведомления о новых ошибках.

Honeybadger предоставляет все необходимое для отслеживания ошибок, возникающих в вашем рабочем приложении. Выполните следующие шаги, чтобы интегрировать его в свое приложение Node.js:

1. Установите пакет

Используйте npm для установки пакета:

2. Импортируйте библиотеку

Импортируйте библиотеку и настройте ее с помощью своего ключа API, чтобы начать сообщать об ошибках:

3. Сообщите об ошибках

Вы можете сообщить об ошибке, вызвав метод notify() , как показано в следующем примере:

Для получения дополнительной информации о том, как Honeybadger интегрируется с веб-фреймворками Node.js, см. полную документацию или ознакомьтесь с образцом приложения Node.js/Express на GitHub.

Резюме

Класс (или подкласс) Error всегда должен быть использован для связи ошибок в коде. Технически, вы можете throw что угодно в JavaScript, а не только объекты Error , но это не рекомендуется, так как это значительно снижает полезность ошибки и делает обработку ошибок подверженной ошибкам. Последовательно используя объекты Error , вы можете надежно рассчитывать на доступ error.message или error.stack в местах, где ошибки обрабатываются или регистрируются. Вы даже можете дополнить класс ошибок другими полезными свойствами, относящимися к контексту, в котором произошла ошибка.

Операционные ошибки неизбежны и должны учитываться в любой корректной программе. В большинстве случаев следует использовать стратегию исправимых ошибок, чтобы программа могла продолжать работать без сбоев. Однако, если ошибка достаточно серьезная, может быть целесообразно завершить программу и перезапустить ее. Попробуйте завершить работу корректно, если возникнут такие ситуации, чтобы программа могла снова запуститься в чистом состоянии.

Ошибки программиста нельзя обработать или исправить, но их можно смягчить с помощью набора автоматизированных тестов и инструментов статической типизации. При написании функции определите поведение для неверных параметров и действуйте соответствующим образом после их обнаружения. Разрешите сбой программы при обнаружении uncaughtException или unhandledRejection . Не пытайтесь исправить такие ошибки!

Используйте службу мониторинга ошибок, например Honeybadger, для сбора и анализа ваших ошибок. Это может помочь вам значительно повысить скорость отладки и разрешения проблем.

Вывод

Правильная обработка ошибок является непреложным требованием, если вы хотите писать хорошее и надежное программное обеспечение. Используя методы, описанные в этой статье, вы будете на правильном пути к этому.