Ошибки¶
Приложения, работающие в Node.js, обычно сталкиваются с четырьмя категориями ошибок:
- Стандартные ошибки JavaScript, такие как {EvalError}, {SyntaxError}, {RangeError}, {ReferenceError}, {TypeError} и {URIError}.
- Системные ошибки, вызванные ограничениями базовой операционной системы, такими как попытка открыть несуществующий файл или попытка отправить данные через закрытый сокет.
- Пользовательские ошибки, вызванные кодом приложения.
AssertionError
s — это особый класс ошибок, который может быть вызван, когда Node.js обнаруживает исключительное логическое нарушение, которое никогда не должно происходить. Обычно они поднимаютсяassert
модуль.
Все ошибки JavaScript и системные ошибки, вызванные Node.js, наследуются от стандартного класса {Error} JavaScript или являются его экземплярами и гарантированно предоставляют по меньшей мере свойства, доступные в этом классе.
Распространение ошибок и перехват¶
Node.js поддерживает несколько механизмов распространения и обработки ошибок, возникающих во время работы приложения. То, как эти ошибки сообщаются и обрабатываются, полностью зависит от типа Error
и стиль вызываемого API.
Все ошибки JavaScript обрабатываются как исключения, которые немедленно генерировать и выдавать ошибку с помощью стандартного JavaScript throw
механизм. Они обрабатываются с помощью try…catch
строить предоставляется языком JavaScript.
// Throws with a ReferenceError because z is not defined.
try {
const m = 1;
const n = m + z;
} catch (err) {
// Handle the error here.
}
Любое использование JavaScript throw
механизм вызовет исключение, которое должен обрабатываться с использованием try…catch
или процесс Node.js немедленно завершится.
За некоторыми исключениями, Синхронный API (любой метод блокировки, не принимающий callback
функция, например fs.readFileSync
), буду использовать throw
сообщать об ошибках.
Ошибки, возникающие внутри Асинхронные API можно сообщить несколькими способами:
- Большинство асинхронных методов, которые принимают
callback
функция приметError
объект, переданный в качестве первого аргумента этой функции. Если этот первый аргумент неnull
и является экземпляромError
, то произошла ошибка, которую необходимо обработать.
const fs = require('fs');
fs.readFile('a file that does not exist', (err, data) => {
if (err) {
console.error(
'There was an error reading the file!',
err
);
return;
}
// Otherwise handle the data
});
- Когда асинхронный метод вызывается для объекта, который является
EventEmitter
, ошибки могут быть перенаправлены на этот объект'error'
событие.
const net = require('net');
const connection = net.connect('localhost');
// Adding an 'error' event handler to a stream:
connection.on('error', (err) => {
// If the connection is reset by the server, or if it can't
// connect at all, or on any sort of error encountered by
// the connection, the error will be sent here.
console.error(err);
});
connection.pipe(process.stdout);
- Некоторые обычно асинхронные методы в API Node.js могут по-прежнему использовать
throw
механизм для создания исключений, которые должны обрабатываться с помощьюtry…catch
. Исчерпывающего списка таких методов нет; обратитесь к документации по каждому методу, чтобы определить соответствующий требуемый механизм обработки ошибок.
Использование 'error'
механизм событий наиболее распространен для потоковый а также на основе эмиттера событий API-интерфейсы, которые сами по себе представляют собой серию асинхронных операций с течением времени (в отличие от одной операции, которая может пройти или закончиться неудачей).
Для все EventEmitter
объекты, если 'error'
обработчик событий не предоставляется, будет выдана ошибка, в результате чего процесс Node.js сообщит о неперехваченном исключении и завершится сбоем, если только одно из следующих событий: domain
модуль используется надлежащим образом или обработчик зарегистрирован для 'uncaughtException'
событие.
const EventEmitter = require('events');
const ee = new EventEmitter();
setImmediate(() => {
// This will crash the process because no 'error' event
// handler has been added.
ee.emit('error', new Error('This will crash'));
});
Ошибки, сгенерированные таким образом не мочь быть перехваченным с помощью try…catch
как они брошены после код вызова уже вышел.
Разработчики должны обращаться к документации по каждому методу, чтобы точно определить, как распространяются ошибки, вызванные этими методами.
Обратные вызовы при первой ошибке¶
Большинство асинхронных методов, предоставляемых основным API Node.js, следуют идиоматическому шаблону, называемому обратный вызов при первой ошибке. В этом шаблоне функция обратного вызова передается методу в качестве аргумента. Когда операция завершается или возникает ошибка, вызывается функция обратного вызова с Error
объект (если есть) передается в качестве первого аргумента. Если ошибки не возникло, первый аргумент будет передан как null
.
const fs = require('fs');
function errorFirstCallback(err, data) {
if (err) {
console.error('There was an error', err);
return;
}
console.log(data);
}
fs.readFile(
'/some/file/that/does-not-exist',
errorFirstCallback
);
fs.readFile(
'/some/file/that/does-exist',
errorFirstCallback
);
JavaScript try…catch
механизм не мочь использоваться для перехвата ошибок, генерируемых асинхронными API. Распространенная ошибка новичков — пытаться использовать throw
внутри обратного вызова с ошибкой:
// THIS WILL NOT WORK:
const fs = require('fs');
try {
fs.readFile(
'/some/file/that/does-not-exist',
(err, data) => {
// Mistaken assumption: throwing here...
if (err) {
throw err;
}
}
);
} catch (err) {
// This will not catch the throw!
console.error(err);
}
Это не сработает, потому что функция обратного вызова передана в fs.readFile()
вызывается асинхронно. К моменту вызова обратного вызова окружающий код, включая try…catch
блок, уже вышли. Выдача ошибки внутри обратного вызова может привести к сбою процесса Node.js в большинстве случаев. Если домены включены, или обработчик был зарегистрирован с process.on('uncaughtException')
, такие ошибки можно перехватить.
Класс: Error
¶
Общий объект JavaScript {Error}, не указывающий на конкретную причину возникновения ошибки. Error
объекты фиксируют «трассировку стека», детализирующую точку в коде, в которой Error
был создан, и может содержать текстовое описание ошибки.
Все ошибки, генерируемые Node.js, включая все системные ошибки и ошибки JavaScript, будут либо экземплярами, либо унаследованы от Error
класс.
new Error(message)
¶
message
{нить}
Создает новый Error
объект и устанавливает error.message
в предоставленное текстовое сообщение. Если объект передается как message
, текстовое сообщение создается при вызове message.toString()
. В error.stack
свойство будет представлять точку в коде, в которой new Error()
назывался. Трассировки стека зависят от API трассировки стека V8. Трассировки стека распространяются только на (а) начало синхронное выполнение кода, или (b) количество кадров, заданное свойством Error.stackTraceLimit
, в зависимости от того, что меньше.
Error.captureStackTrace(targetObject[, constructorOpt])
¶
targetObject
{Объект}constructorOpt
{Функция}
Создает .stack
собственность на targetObject
, который при доступе возвращает строку, представляющую место в коде, в котором Error.captureStackTrace()
назывался.
const myObject = {};
Error.captureStackTrace(myObject);
myObject.stack; // Similar to `new Error().stack`
Первая строка трассировки будет иметь префикс ${myObject.name}: ${myObject.message}
.
Необязательный constructorOpt
Аргумент принимает функцию. Если указано, все кадры выше constructorOpt
, включая constructorOpt
, будет исключен из сгенерированной трассировки стека.
В constructorOpt
Аргумент полезен для сокрытия деталей реализации генерации ошибок от пользователя. Например:
function MyError() {
Error.captureStackTrace(this, MyError);
}
// Without passing MyError to captureStackTrace, the MyError
// frame would show up in the .stack property. By passing
// the constructor, we omit that frame, and retain all frames below it.
new MyError().stack;
Error.stackTraceLimit
¶
- {количество}
В Error.stackTraceLimit
указывает количество кадров стека, собранных трассировкой стека (независимо от того, сгенерированы ли они new Error().stack
или Error.captureStackTrace(obj)
).
Значение по умолчанию — 10
но может быть установлен на любой допустимый номер JavaScript. Изменения повлияют на любую записанную трассировку стека. после значение было изменено.
Если установлено нечисловое значение или задано отрицательное число, трассировки стека не будут захватывать какие-либо кадры.
error.code
¶
- {нить}
В error.code
Свойство — это строковая метка, определяющая тип ошибки. error.code
это наиболее стабильный способ выявления ошибки. Он будет меняться только между основными версиями Node.js. Наоборот, error.message
строки могут меняться между любыми версиями Node.js. Видеть Коды ошибок Node.js для получения подробной информации о конкретных кодах.
error.message
¶
- {нить}
В error.message
свойство — это строковое описание ошибки, установленное при вызове new Error(message)
. В message
переданный конструктору, также появится в первой строке трассировки стека Error
, однако изменение этого свойства после Error
объект создан может нет изменить первую строку трассировки стека (например, когда error.stack
читается до изменения этого свойства).
const err = new Error('The message');
console.error(err.message);
// Prints: The message
error.stack
¶
- {нить}
В error.stack
свойство — это строка, описывающая точку в коде, в которой Error
был создан.
Error: Things keep happening!
at /home/gbusey/file.js:525:2
at Frobnicator.refrobulate (/home/gbusey/business-logic.js:424:21)
at Actor.<anonymous> (/home/gbusey/actors.js:400:8)
at increaseSynergy (/home/gbusey/actors.js:701:6)
Первая строка отформатирована как <error class name>: <error message>
, за которым следует серия кадров стека (каждая строка начинается с «at»). Каждый фрейм описывает сайт вызова в коде, который приводит к сгенерированной ошибке. V8 пытается отобразить имя для каждой функции (по имени переменной, имени функции или имени метода объекта), но иногда не может найти подходящее имя. Если V8 не может определить имя функции, для этого фрейма будет отображаться только информация о местоположении. В противном случае определенное имя функции будет отображаться с информацией о местоположении, добавленной в круглые скобки.
Фреймы создаются только для функций JavaScript. Если, например, выполнение синхронно проходит через дополнительную функцию C ++, называемую cheetahify
который сам вызывает функцию JavaScript, фрейм, представляющий cheetahify
вызов не будет присутствовать в трассировке стека:
const cheetahify = require('./native-binding.node');
function makeFaster() {
// `cheetahify()` *synchronously* calls speedy.
cheetahify(function speedy() {
throw new Error('oh no!');
});
}
makeFaster();
// will throw:
// /home/gbusey/file.js:6
// throw new Error('oh no!');
// ^
// Error: oh no!
// at speedy (/home/gbusey/file.js:6:11)
// at makeFaster (/home/gbusey/file.js:5:3)
// at Object.<anonymous> (/home/gbusey/file.js:10:1)
// at Module._compile (module.js:456:26)
// at Object.Module._extensions..js (module.js:474:10)
// at Module.load (module.js:356:32)
// at Function.Module._load (module.js:312:12)
// at Function.Module.runMain (module.js:497:10)
// at startup (node.js:119:16)
// at node.js:906:3
Информация о местоположении будет одной из следующих:
native
, если кадр представляет внутренний вызов V8 (как в[].forEach
).plain-filename.js:line:column
, если фрейм представляет собой внутренний вызов Node.js./absolute/path/to/file.js:line:column
, если кадр представляет собой вызов в пользовательской программе или ее зависимостях.
Строка, представляющая трассировку стека, генерируется лениво, когда error.stack
собственность доступ.
Количество кадров, захваченных трассировкой стека, ограничено меньшим из Error.stackTraceLimit
или количество доступных кадров в текущем тике цикла событий.
Класс: AssertionError
¶
- Расширяется: {errors.Error}
Указывает на неудачу утверждения. Подробнее см. Class: assert.AssertionError
.
Класс: RangeError
¶
- Расширяется: {errors.Error}
Указывает, что предоставленный аргумент находится за пределами набора или диапазона допустимых значений для функции; является ли это числовым диапазоном или вне набора опций для данного параметра функции.
require('net').connect(-1);
// Throws "RangeError: "port" option should be >= 0 and < 65536: -1"
Node.js сгенерирует и выбросит RangeError
экземпляры немедленно как форма подтверждения аргумента.
Класс: ReferenceError
¶
- Расширяется: {errors.Error}
Указывает, что предпринимается попытка получить доступ к переменной, которая не определена. Такие ошибки обычно указывают на опечатки в коде или на некорректную программу.
Хотя клиентский код может генерировать и распространять эти ошибки, на практике это будет делать только V8.
doesNotExist;
// Throws ReferenceError, doesNotExist is not a variable in this program.
Если приложение динамически не генерирует и не запускает код, ReferenceError
экземпляры указывают на ошибку в коде или его зависимостях.
Класс: SyntaxError
¶
- Расширяется: {errors.Error}
Указывает, что программа не является допустимым JavaScript. Эти ошибки могут возникать и распространяться только в результате оценки кода. Оценка кода может произойти в результате eval
, Function
, require
, или vm. Эти ошибки почти всегда указывают на неработающую программу.
try {
require('vm').runInThisContext('binary ! isNotOk');
} catch (err) {
// 'err' will be a SyntaxError.
}
SyntaxError
экземпляры невозможно восстановить в контексте, который их создал — они могут быть перехвачены только в других контекстах.
Класс: SystemError
¶
- Расширяется: {errors.Error}
Node.js генерирует системные ошибки, когда в среде выполнения возникают исключения. Обычно это происходит, когда приложение нарушает ограничение операционной системы. Например, системная ошибка произойдет, если приложение попытается прочитать несуществующий файл.
address
{строка} Если присутствует, адрес, к которому не удалось подключиться к сети.code
{строка} Код ошибки строкиdest
{строка} Если присутствует, путь к файлу при сообщении об ошибке файловой системыerrno
{number} Номер ошибки, предоставленный системойinfo
{Object} Если присутствует, дополнительные сведения о состоянии ошибкиmessage
{string} Предоставляемое системой описание ошибки в удобной для чтения форме.path
{строка} Если присутствует, путь к файлу при сообщении об ошибке файловой системыport
{number} Если присутствует, порт сетевого подключения, который недоступенsyscall
{строка} Имя системного вызова, вызвавшего ошибку
error.address
¶
- {нить}
Если представить, error.address
— это строка, описывающая адрес, к которому не удалось установить сетевое соединение.
error.code
¶
- {нить}
В error.code
свойство — это строка, представляющая код ошибки.
error.dest
¶
- {нить}
Если представить, error.dest
— это путь к файлу при сообщении об ошибке файловой системы.
error.errno
¶
- {количество}
В error.errno
свойство — отрицательное число, которое соответствует коду ошибки, определенному в libuv Error handling
.
В Windows номер ошибки, предоставленный системой, будет нормализован libuv.
Чтобы получить строковое представление кода ошибки, используйте util.getSystemErrorName(error.errno)
.
error.info
¶
- {Объект}
Если представить, error.info
— объект с подробной информацией о состоянии ошибки.
error.message
¶
- {нить}
error.message
представляет собой удобочитаемое описание ошибки, предоставляемое системой.
error.path
¶
- {нить}
Если представить, error.path
— строка, содержащая соответствующий недопустимый путь.
error.port
¶
- {количество}
Если представить, error.port
порт сетевого подключения недоступен.
error.syscall
¶
- {нить}
В error.syscall
свойство — это строка, описывающая системный вызов это не удалось.
Общие системные ошибки¶
Это список системных ошибок, которые часто встречаются при написании программы на Node.js. Полный список см. В errno
(3) справочная страница.
-
EACCES
(В разрешении отказано): была сделана попытка получить доступ к файлу способом, запрещенным его разрешениями на доступ к файлу. -
EADDRINUSE
(Адрес уже используется): попытка привязать сервер (net
,http
, илиhttps
) на локальный адрес не удалось из-за того, что другой сервер в локальной системе уже занимает этот адрес. -
ECONNREFUSED
(В соединении отказано): соединение не может быть установлено, потому что целевая машина активно отказалась от него. Обычно это происходит из-за попытки подключиться к неактивной службе на чужом хосте. -
ECONNRESET
(Сброс соединения одноранговым узлом): соединение было принудительно закрыто одноранговым узлом. Обычно это происходит из-за потери соединения с удаленным сокетом из-за тайм-аута или перезагрузки. Обычно встречается черезhttp
а такжеnet
модули. -
EEXIST
(Файл существует): существующий файл был целью операции, которая требовала, чтобы цель не существовала. -
EISDIR
(Является каталогом): операция ожидала файл, но указанный путь был каталогом. -
EMFILE
(Слишком много открытых файлов в системе): максимальное количество файловые дескрипторы допустимый в системе, и запросы для другого дескриптора не могут быть выполнены, пока хотя бы один из них не будет закрыт. Это происходит при одновременном открытии множества файлов одновременно, особенно в системах (в частности, macOS), где существует низкий предел дескрипторов файлов для процессов. Чтобы исправить низкий предел, запуститеulimit -n 2048
в той же оболочке, которая будет запускать процесс Node.js. -
ENOENT
(Нет такого файла или каталога): обычно создаетсяfs
операции, чтобы указать, что компонент указанного пути не существует. По указанному пути не удалось найти ни один объект (файл или каталог). -
ENOTDIR
(Не каталог): компонент с указанным путем существует, но не является каталогом, как ожидалось. Обычно выращиваетсяfs.readdir
. -
ENOTEMPTY
(Каталог не пустой): каталог с записями был целью операции, для которой требуется пустой каталог, обычноfs.unlink
. -
ENOTFOUND
(Ошибка поиска DNS): указывает на сбой DNS либоEAI_NODATA
илиEAI_NONAME
. Это не стандартная ошибка POSIX. -
EPERM
(Операция запрещена): была сделана попытка выполнить операцию, требующую повышенных привилегий. -
EPIPE
(Сломанный канал): запись в канал, сокет или FIFO, для которого нет процесса для чтения данных. Часто встречается наnet
а такжеhttp
Уровни, указывающие на то, что удаленная сторона записываемого потока была закрыта. -
ETIMEDOUT
(Превышено время ожидания операции): запрос на подключение или отправку завершился неудачно, поскольку подключенная сторона не ответила должным образом по прошествии определенного периода времени. Обычно встречаетсяhttp
илиnet
. Часто признак того, чтоsocket.end()
не был должным образом назван.
Класс: TypeError
¶
- Расширяет {errors.Error}
Указывает, что указанный аргумент не является допустимым типом. Например, передача функции параметру, который ожидает строку, будет TypeError
.
require('url').parse(() => {});
// Throws TypeError, since it expected a string.
Node.js сгенерирует и выбросит TypeError
экземпляры немедленно как форма подтверждения аргумента.
Исключения против ошибок¶
Исключение JavaScript — это значение, которое выбрасывается в результате недопустимой операции или как цель throw
утверждение. Хотя не требуется, чтобы эти значения были экземплярами Error
или классы, которые наследуются от Error
, все исключения, создаваемые Node.js или средой выполнения JavaScript буду быть экземплярами Error
.
Некоторые исключения безвозвратно на уровне JavaScript. Такие исключения будут всегда вызвать сбой процесса Node.js. Примеры включают assert()
чеки или abort()
вызывает в слое C ++.
Ошибки OpenSSL¶
Ошибки, возникающие в crypto
или tls
классные Error
, и в дополнение к стандартному .code
а также .message
properties, могут иметь некоторые дополнительные свойства, специфичные для OpenSSL.
error.opensslErrorStack
¶
Массив ошибок, который может дать контекст, откуда в библиотеке OpenSSL возникла ошибка.
error.function
¶
Функция OpenSSL, в которой возникла ошибка.
error.library
¶
Библиотека OpenSSL, в которой возникла ошибка.
error.reason
¶
Строка в удобном для чтения виде, описывающая причину ошибки.
ABORT_ERR
¶
Используется, когда операция была прервана (обычно с использованием AbortController
).
API нет с использованием AbortSignal
s обычно не вызывают ошибки с этим кодом.
Этот код не использует обычный ERR_*
соглашение об ошибках Node.js используется для обеспечения совместимости с веб-платформой. AbortError
.
ERR_AMBIGUOUS_ARGUMENT
¶
Аргумент функции используется таким образом, чтобы предположить, что сигнатура функции может быть неправильно понята. Это брошено assert
модуль, когда message
параметр в assert.throws(block, message)
совпадает с сообщением об ошибке, выданным block
потому что это использование предполагает, что пользователь верит message
ожидаемое сообщение, а не сообщение AssertionError
будет отображаться, если block
не бросает.
ERR_ARG_NOT_ITERABLE
¶
Итерируемый аргумент (т.е. значение, которое работает с for...of
loops) требуется, но не предоставляется API Node.js.
ERR_ASSERTION
¶
Особый тип ошибки, которая может быть вызвана всякий раз, когда Node.js обнаруживает исключительное логическое нарушение, которое никогда не должно происходить. Обычно они поднимаются assert
модуль.
ERR_ASYNC_CALLBACK
¶
Была сделана попытка зарегистрировать что-то, что не является функцией, как AsyncHooks
Перезвоните.
ERR_ASYNC_TYPE
¶
Недопустимый тип асинхронного ресурса. Пользователи также могут определять свои собственные типы при использовании общедоступного API для встраивания.
ERR_BROTLI_COMPRESSION_FAILED
¶
Данные, переданные в поток Brotli, не были успешно сжаты.
ERR_BROTLI_INVALID_PARAM
¶
Во время построения потока Brotli был передан недопустимый ключ параметра.
ERR_BUFFER_CONTEXT_NOT_AVAILABLE
¶
Была сделана попытка создать Node.js Buffer
из кода надстройки или встраивания, находясь в контексте механизма JS, который не связан с экземпляром Node.js. Данные, переданные в Buffer
будет выпущен к тому времени, когда метод вернется.
При возникновении этой ошибки возможная альтернатива созданию Buffer
пример — создать нормальный Uint8Array
, который отличается только прототипом результирующего объекта. Uint8Array
s общеприняты во всех основных API Node.js, где Buffer
s есть; они доступны во всех контекстах.
ERR_BUFFER_OUT_OF_BOUNDS
¶
Операция за пределами Buffer
была предпринята попытка.
ERR_BUFFER_TOO_LARGE
¶
Была сделана попытка создать Buffer
больше максимально допустимого размера.
ERR_CANNOT_WATCH_SIGINT
¶
Node.js не смог отследить SIGINT
сигнал.
ERR_CHILD_CLOSED_BEFORE_REPLY
¶
Дочерний процесс был закрыт до того, как родительский процесс получил ответ.
ERR_CHILD_PROCESS_IPC_REQUIRED
¶
Используется, когда дочерний процесс разветвляется без указания канала IPC.
ERR_CHILD_PROCESS_STDIO_MAXBUFFER
¶
Используется, когда основной процесс пытается прочитать данные из STDERR / STDOUT дочернего процесса, и длина данных больше, чем maxBuffer
вариант.
ERR_CLOSED_MESSAGE_PORT
¶
Была попытка использовать MessagePort
экземпляр в закрытом состоянии, обычно после .close()
был вызван.
ERR_CONSOLE_WRITABLE_STREAM
¶
Console
был создан без stdout
поток, или Console
имеет незаписываемый stdout
или stderr
транслировать.
ERR_CONSTRUCT_CALL_INVALID
¶
Был вызван конструктор класса, который нельзя вызвать.
ERR_CONSTRUCT_CALL_REQUIRED
¶
Конструктор класса был вызван без new
.
ERR_CONTEXT_NOT_INITIALIZED
¶
Контекст vm, переданный в API, еще не инициализирован. Это может произойти при возникновении (и обнаружении) ошибки во время создания контекста, например, при сбое выделения или при достижении максимального размера стека вызовов при создании контекста.
ERR_CRYPTO_CUSTOM_ENGINE_NOT_SUPPORTED
¶
Был запрошен механизм сертификатов клиента, который не поддерживается используемой версией OpenSSL.
ERR_CRYPTO_ECDH_INVALID_FORMAT
¶
Недопустимое значение для format
аргумент был передан crypto.ECDH()
класс getPublicKey()
метод.
ERR_CRYPTO_ECDH_INVALID_PUBLIC_KEY
¶
Недопустимое значение для key
аргумент был передан crypto.ECDH()
класс computeSecret()
метод. Это означает, что открытый ключ лежит за пределами эллиптической кривой.
ERR_CRYPTO_ENGINE_UNKNOWN
¶
Неверный идентификатор криптографической машины был передан в require('crypto').setEngine()
.
ERR_CRYPTO_FIPS_FORCED
¶
В --force-fips
был использован аргумент командной строки, но была попытка включить или отключить режим FIPS в crypto
модуль.
ERR_CRYPTO_FIPS_UNAVAILABLE
¶
Была сделана попытка включить или отключить режим FIPS, но режим FIPS был недоступен.
ERR_CRYPTO_HASH_FINALIZED
¶
hash.digest()
вызвали несколько раз. В hash.digest()
метод должен вызываться не более одного раза для каждого экземпляра Hash
объект.
ERR_CRYPTO_HASH_UPDATE_FAILED
¶
hash.update()
не удалось по какой-либо причине. Это должно происходить редко, если вообще когда-либо случаться.
ERR_CRYPTO_INCOMPATIBLE_KEY
¶
Указанные криптографические ключи несовместимы с предпринятой операцией.
ERR_CRYPTO_INCOMPATIBLE_KEY_OPTIONS
¶
Выбранная кодировка открытого или закрытого ключа несовместима с другими параметрами.
ERR_CRYPTO_INITIALIZATION_FAILED
¶
Не удалось инициализировать криптоподсистему.
ERR_CRYPTO_INVALID_AUTH_TAG
¶
Предоставлен недопустимый тег аутентификации.
ERR_CRYPTO_INVALID_COUNTER
¶
Для шифра режима противодействия предоставлен неверный счетчик.
ERR_CRYPTO_INVALID_CURVE
¶
Была предоставлена неверная эллиптическая кривая.
ERR_CRYPTO_INVALID_DIGEST
¶
Недействительный алгоритм криптодайджеста было указано.
ERR_CRYPTO_INVALID_IV
¶
Предоставлен недопустимый вектор инициализации.
ERR_CRYPTO_INVALID_JWK
¶
Был предоставлен недопустимый веб-ключ JSON.
ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE
¶
Данный тип объекта криптографического ключа недопустим для выполняемой операции.
ERR_CRYPTO_INVALID_KEYLEN
¶
Была предоставлена неверная длина ключа.
ERR_CRYPTO_INVALID_KEYPAIR
¶
Была предоставлена неверная пара ключей.
ERR_CRYPTO_INVALID_KEYTYPE
¶
Предоставлен недопустимый тип ключа.
ERR_CRYPTO_INVALID_MESSAGELEN
¶
Была предоставлена неверная длина сообщения.
ERR_CRYPTO_INVALID_SCRYPT_PARAMS
¶
Были предоставлены неверные параметры алгоритма шифрования.
ERR_CRYPTO_INVALID_STATE
¶
Крипто-метод был использован для объекта, находившегося в недопустимом состоянии. Например, позвонив cipher.getAuthTag()
перед звонком cipher.final()
.
ERR_CRYPTO_INVALID_TAG_LENGTH
¶
Предоставлена неверная длина тега аутентификации.
ERR_CRYPTO_JOB_INIT_FAILED
¶
Не удалось инициализировать асинхронную криптооперацию.
ERR_CRYPTO_JWK_UNSUPPORTED_CURVE
¶
Эллиптическая кривая Ключа не зарегистрирована для использования в Реестр эллиптических кривых веб-ключей JSON.
ERR_CRYPTO_JWK_UNSUPPORTED_KEY_TYPE
¶
Тип асимметричного ключа ключа не зарегистрирован для использования в Реестр типов веб-ключей JSON.
ERR_CRYPTO_OPERATION_FAILED
¶
Криптооперация завершилась неудачно по неустановленной причине.
ERR_CRYPTO_PBKDF2_ERROR
¶
Алгоритм PBKDF2 завершился неудачно по неустановленным причинам. OpenSSL не предоставляет более подробной информации, и, следовательно, Node.js.
ERR_CRYPTO_SCRYPT_INVALID_PARAMETER
¶
Один или больше crypto.scrypt()
или crypto.scryptSync()
параметры находятся за пределами допустимого диапазона.
ERR_CRYPTO_SCRYPT_NOT_SUPPORTED
¶
Node.js был скомпилирован без scrypt
служба поддержки. Невозможно с официальными двоичными файлами выпуска, но может произойти с пользовательскими сборками, включая сборки дистрибутива.
ERR_CRYPTO_SIGN_KEY_REQUIRED
¶
Подпись key
не был предоставлен sign.sign()
метод.
ERR_CRYPTO_TIMING_SAFE_EQUAL_LENGTH
¶
crypto.timingSafeEqual()
был вызван с Buffer
, TypedArray
, или DataView
аргументы разной длины.
ERR_CRYPTO_UNKNOWN_CIPHER
¶
Указан неизвестный шифр.
ERR_CRYPTO_UNKNOWN_DH_GROUP
¶
Было дано неизвестное название группы Диффи-Хеллмана. Видеть crypto.getDiffieHellman()
для списка допустимых имен групп.
ERR_CRYPTO_UNSUPPORTED_OPERATION
¶
Была сделана попытка вызвать неподдерживаемую криптографическую операцию.
ERR_DEBUGGER_ERROR
¶
Произошла ошибка с отладчик.
ERR_DEBUGGER_STARTUP_ERROR
¶
В отладчик истекло время ожидания освобождения необходимого хоста / порта.
ERR_DLOPEN_DISABLED
¶
Загрузка собственных надстроек отключена с помощью --no-addons
.
ERR_DLOPEN_FAILED
¶
Звонок в process.dlopen()
не смогли.
ERR_DIR_CLOSED
¶
В fs.Dir
ранее был закрыт.
ERR_DIR_CONCURRENT_OPERATION
¶
Была предпринята попытка синхронного чтения или закрытия fs.Dir
который имеет текущие асинхронные операции.
ERR_DNS_SET_SERVERS_FAILED
¶
c-ares
не удалось установить DNS-сервер.
ERR_DOMAIN_CALLBACK_NOT_AVAILABLE
¶
В domain
модуль нельзя было использовать, так как он не мог установить требуемые перехватчики обработки ошибок, потому что process.setUncaughtExceptionCaptureCallback()
был вызван в более ранний момент времени.
ERR_DOMAIN_CANNOT_SET_UNCAUGHT_EXCEPTION_CAPTURE
¶
process.setUncaughtExceptionCaptureCallback()
нельзя было назвать, потому что domain
модуль был загружен раньше.
Трассировка стека расширяется, чтобы включить момент времени, в который domain
модуль был загружен.
ERR_ENCODING_INVALID_ENCODED_DATA
¶
Данные предоставлены TextDecoder()
API был недопустимым в соответствии с предоставленной кодировкой.
ERR_ENCODING_NOT_SUPPORTED
¶
Кодировка предоставлена TextDecoder()
API не был одним из WHATWG Поддерживаемые кодировки.
ERR_EVAL_ESM_CANNOT_PRINT
¶
--print
не может использоваться с входом ESM.
ERR_EVENT_RECURSION
¶
Вызывается, когда делается попытка рекурсивно отправить событие на EventTarget
.
ERR_EXECUTION_ENVIRONMENT_NOT_AVAILABLE
¶
Контекст выполнения JS не связан со средой Node.js. Это может произойти, если Node.js используется в качестве встроенной библиотеки и некоторые хуки для движка JS не настроены должным образом.
ERR_FALSY_VALUE_REJECTION
¶
А Promise
это было выполнено обратным вызовом через util.callbackify()
был отклонен с ложным значением.
ERR_FEATURE_UNAVAILABLE_ON_PLATFORM
¶
Используется, когда используется функция, недоступная для текущей платформы, на которой работает Node.js.
ERR_FS_CP_DIR_TO_NON_DIR
¶
Была сделана попытка скопировать каталог в не каталог (файл, символическую ссылку и т. Д.) С помощью fs.cp()
.
ERR_FS_CP_EEXIST
¶
Была сделана попытка скопировать файл, который уже существовал с fs.cp()
, с force
а также errorOnExist
установлен в true
.
ERR_FS_CP_EINVAL
¶
Когда используешь fs.cp()
, src
или dest
указал на недопустимый путь.
ERR_FS_CP_FIFO_PIPE
¶
Была сделана попытка скопировать именованный канал с fs.cp()
.
ERR_FS_CP_NON_DIR_TO_DIR
¶
Была сделана попытка скопировать не каталог (файл, символическую ссылку и т. Д.) В каталог с помощью fs.cp()
.
ERR_FS_CP_SOCKET
¶
Была сделана попытка скопировать в сокет с fs.cp()
.
ERR_FS_CP_SYMLINK_TO_SUBDIRECTORY
¶
Когда используешь fs.cp()
, символическая ссылка в dest
указал на подкаталог src
.
ERR_FS_CP_UNKNOWN
¶
Была сделана попытка скопировать файл неизвестного типа с fs.cp()
.
ERR_FS_EISDIR
¶
Путь — это каталог.
ERR_FS_FILE_TOO_LARGE
¶
Была сделана попытка прочитать файл, размер которого превышает максимально допустимый размер для Buffer
.
ERR_FS_INVALID_SYMLINK_TYPE
¶
Недопустимый тип символической ссылки был передан в fs.symlink()
или fs.symlinkSync()
методы.
Была сделана попытка добавить дополнительные заголовки после того, как они уже были отправлены.
Указано недопустимое значение заголовка HTTP.
ERR_HTTP_INVALID_STATUS_CODE
¶
Код состояния находился за пределами обычного диапазона кодов состояния (100–999).
ERR_HTTP_REQUEST_TIMEOUT
¶
Клиент не отправил весь запрос в отведенное время.
ERR_HTTP_SOCKET_ENCODING
¶
Изменение кодировки сокета запрещено RFC 7230, раздел 3.
ERR_HTTP_TRAILER_INVALID
¶
В Trailer
заголовок был установлен, хотя кодировка передачи не поддерживает это.
ERR_HTTP2_ALTSVC_INVALID_ORIGIN
¶
Для фреймов HTTP / 2 ALTSVC требуется действительное происхождение.
ERR_HTTP2_ALTSVC_LENGTH
¶
Кадры HTTP / 2 ALTSVC ограничены максимум 16 382 байтами полезной нагрузки.
Для запросов HTTP / 2 с использованием CONNECT
метод, :authority
псевдозаголовок обязателен.
ERR_HTTP2_CONNECT_PATH
¶
Для запросов HTTP / 2 с использованием CONNECT
метод, :path
псевдозаголовок запрещен.
ERR_HTTP2_CONNECT_SCHEME
¶
Для запросов HTTP / 2 с использованием CONNECT
метод, :scheme
псевдозаголовок запрещен.
ERR_HTTP2_ERROR
¶
Произошла неспецифическая ошибка HTTP / 2.
ERR_HTTP2_GOAWAY_SESSION
¶
Новые потоки HTTP / 2 нельзя открывать после Http2Session
получил GOAWAY
кадр от подключенного однорангового узла.
Было предоставлено несколько значений для поля заголовка HTTP / 2, которое должно было иметь только одно значение.
Дополнительные заголовки были указаны после того, как был инициирован ответ HTTP / 2.
Была сделана попытка отправить несколько заголовков ответа.
ERR_HTTP2_INFO_STATUS_NOT_ALLOWED
¶
Информационные коды состояния HTTP (1xx
) не может быть установлен в качестве кода состояния ответа в ответах HTTP / 2.
Заголовки соединения HTTP / 1 запрещено использовать в запросах и ответах HTTP / 2.
Указано недопустимое значение заголовка HTTP / 2.
ERR_HTTP2_INVALID_INFO_STATUS
¶
Указан недопустимый информационный код состояния HTTP. Информационные коды состояния должны быть целыми числами между 100
а также 199
(включительно).
ERR_HTTP2_INVALID_ORIGIN
¶
HTTP / 2 ORIGIN
кадры требуют действительного происхождения.
ERR_HTTP2_INVALID_PACKED_SETTINGS_LENGTH
¶
Вход Buffer
а также Uint8Array
экземпляры переданы в http2.getUnpackedSettings()
API должен иметь длину, кратную шести.
Только допустимые псевдозаголовки HTTP / 2 (:status
, :path
, :authority
, :scheme
, а также :method
) может быть использовано.
ERR_HTTP2_INVALID_SESSION
¶
Действие было выполнено с Http2Session
объект, который уже был уничтожен.
ERR_HTTP2_INVALID_SETTING_VALUE
¶
Для параметра HTTP / 2 указано недопустимое значение.
ERR_HTTP2_INVALID_STREAM
¶
Операция была выполнена над потоком, который уже был уничтожен.
ERR_HTTP2_MAX_PENDING_SETTINGS_ACK
¶
Всякий раз, когда HTTP / 2 SETTINGS
фрейм отправляется подключенному одноранговому узлу, одноранговый узел должен отправить подтверждение, что он получил и применил новый SETTINGS
. По умолчанию максимальное количество неподтвержденных SETTINGS
кадры могут быть отправлены в любой момент времени. Этот код ошибки используется при достижении этого предела.
ERR_HTTP2_NESTED_PUSH
¶
Была сделана попытка инициировать новый push-поток из push-потока. Вложенные push-потоки не разрешены.
ERR_HTTP2_NO_MEM
¶
Недостаточно памяти при использовании http2session.setLocalWindowSize(windowSize)
API.
ERR_HTTP2_NO_SOCKET_MANIPULATION
¶
Была предпринята попытка напрямую манипулировать (чтение, запись, пауза, возобновление и т. Д.) Сокетом, подключенным к Http2Session
.
ERR_HTTP2_ORIGIN_LENGTH
¶
HTTP / 2 ORIGIN
кадры ограничены длиной 16382 байта.
ERR_HTTP2_OUT_OF_STREAMS
¶
Количество потоков, созданных в одном сеансе HTTP / 2, достигло максимального предела.
ERR_HTTP2_PAYLOAD_FORBIDDEN
¶
Полезная нагрузка сообщения была указана для кода ответа HTTP, для которого полезная нагрузка запрещена.
ERR_HTTP2_PING_CANCEL
¶
Пинг HTTP / 2 был отменен.
ERR_HTTP2_PING_LENGTH
¶
Полезные данные ping HTTP / 2 должны иметь длину ровно 8 байтов.
Псевдозаголовок HTTP / 2 использован ненадлежащим образом. Псевдо-заголовки — это имена ключей заголовков, которые начинаются с :
приставка.
ERR_HTTP2_PUSH_DISABLED
¶
Была сделана попытка создать push-поток, который был отключен клиентом.
ERR_HTTP2_SEND_FILE
¶
Была сделана попытка использовать Http2Stream.prototype.responseWithFile()
API для отправки каталога.
ERR_HTTP2_SEND_FILE_NOSEEK
¶
Была сделана попытка использовать Http2Stream.prototype.responseWithFile()
API для отправки чего-то другого, кроме обычного файла, но offset
или length
были предоставлены варианты.
ERR_HTTP2_SESSION_ERROR
¶
В Http2Session
закрывается с ненулевым кодом ошибки.
ERR_HTTP2_SETTINGS_CANCEL
¶
В Http2Session
настройки отменены.
ERR_HTTP2_SOCKET_BOUND
¶
Была сделана попытка подключить Http2Session
возражать против net.Socket
или tls.TLSSocket
который уже был привязан к другому Http2Session
объект.
ERR_HTTP2_SOCKET_UNBOUND
¶
Была сделана попытка использовать socket
собственность Http2Session
это уже было закрыто.
ERR_HTTP2_STATUS_101
¶
Использование 101
Информационный код статуса запрещен в HTTP / 2.
ERR_HTTP2_STATUS_INVALID
¶
Указан недопустимый код состояния HTTP. Коды состояния должны быть целыми числами между 100
а также 599
(включительно).
ERR_HTTP2_STREAM_CANCEL
¶
An Http2Stream
был уничтожен до того, как какие-либо данные были переданы подключенному узлу.
ERR_HTTP2_STREAM_ERROR
¶
Ненулевой код ошибки был указан в RST_STREAM
Рамка.
ERR_HTTP2_STREAM_SELF_DEPENDENCY
¶
При установке приоритета для потока HTTP / 2 этот поток может быть помечен как зависимость для родительского потока. Этот код ошибки используется, когда делается попытка пометить поток и зависит от него самого.
ERR_HTTP2_TOO_MANY_INVALID_FRAMES
¶
Предел приемлемых недопустимых кадров протокола HTTP / 2, отправленных партнером, как указано в maxSessionInvalidFrames
вариант, был превышен.
ERR_HTTP2_TRAILERS_ALREADY_SENT
¶
Конечные заголовки уже отправлены на Http2Stream
.
ERR_HTTP2_TRAILERS_NOT_READY
¶
В http2stream.sendTrailers()
метод не может быть вызван до тех пор, пока 'wantTrailers'
событие испускается на Http2Stream
объект. В 'wantTrailers'
событие будет сгенерировано только в том случае, если waitForTrailers
опция установлена для Http2Stream
.
ERR_HTTP2_UNSUPPORTED_PROTOCOL
¶
http2.connect()
был передан URL-адрес, использующий любой протокол, кроме http:
или https:
.
ERR_ILLEGAL_CONSTRUCTOR
¶
Была предпринята попытка построить объект с использованием закрытого конструктора.
ERR_INCOMPATIBLE_OPTION_PAIR
¶
Пара опций несовместима друг с другом и не может использоваться одновременно.
ERR_INPUT_TYPE_NOT_ALLOWED
¶
Стабильность: 1 — экспериментальная
В --input-type
Флаг использовался для попытки выполнить файл. Этот флаг можно использовать только при вводе через --eval
, --print
или STDIN
.
ERR_INSPECTOR_ALREADY_ACTIVATED
¶
При использовании inspector
module была предпринята попытка активировать инспектор, когда он уже начал прослушивать порт. Использовать inspector.close()
прежде чем активировать его на другом адресе.
ERR_INSPECTOR_ALREADY_CONNECTED
¶
При использовании inspector
модуль, была предпринята попытка подключения, когда инспектор уже был подключен.
ERR_INSPECTOR_CLOSED
¶
При использовании inspector
модуля, была предпринята попытка использовать инспектор после того, как сессия уже закрылась.
ERR_INSPECTOR_COMMAND
¶
Произошла ошибка при подаче команды через inspector
модуль.
ERR_INSPECTOR_NOT_ACTIVE
¶
В inspector
не активен, когда inspector.waitForDebugger()
называется.
ERR_INSPECTOR_NOT_AVAILABLE
¶
В inspector
модуль недоступен для использования.
ERR_INSPECTOR_NOT_CONNECTED
¶
При использовании inspector
модуль, была предпринята попытка использовать инспектор до его подключения.
ERR_INSPECTOR_NOT_WORKER
¶
В основном потоке был вызван API, который можно использовать только из рабочего потока.
ERR_INTERNAL_ASSERTION
¶
Ошибка в Node.js или некорректное использование внутренних компонентов Node.js. Чтобы исправить ошибку, откройте проблему на https://github.com/nodejs/node/issues.
ERR_INVALID_ADDRESS_FAMILY
¶
Указанное семейство адресов не распознается API Node.js.
ERR_INVALID_ARG_TYPE
¶
В API Node.js был передан аргумент неправильного типа.
ERR_INVALID_ARG_VALUE
¶
Для данного аргумента было передано недопустимое или неподдерживаемое значение.
ERR_INVALID_ASYNC_ID
¶
Недействительный asyncId
или triggerAsyncId
был передан с использованием AsyncHooks
. Идентификатор меньше -1 никогда не должен происходить.
ERR_INVALID_BUFFER_SIZE
¶
Обмен был произведен на Buffer
но его размер был несовместим с операцией.
ERR_INVALID_CALLBACK
¶
Требовалась функция обратного вызова, но она не была предоставлена API Node.js.
ERR_INVALID_CHAR
¶
В заголовках обнаружены недопустимые символы.
ERR_INVALID_CURSOR_POS
¶
Курсор в данном потоке нельзя переместить в указанную строку без указанного столбца.
ERR_INVALID_FD
¶
Дескриптор файла (‘fd’) недействителен (например, имеет отрицательное значение).
ERR_INVALID_FD_TYPE
¶
Недопустимый тип дескриптора файла (‘fd’).
ERR_INVALID_FILE_URL_HOST
¶
API-интерфейс Node.js, который потребляет file:
URL-адреса (например, определенные функции в fs
module) обнаружил URL-адрес файла с несовместимым хостом. Эта ситуация может возникнуть только в Unix-подобных системах, где только localhost
или поддерживается пустой хост.
ERR_INVALID_FILE_URL_PATH
¶
API-интерфейс Node.js, который потребляет file:
URL-адреса (например, определенные функции в fs
module) обнаружил URL-адрес файла с несовместимым путем. Точная семантика для определения возможности использования пути зависит от платформы.
ERR_INVALID_HANDLE_TYPE
¶
Была сделана попытка отправить неподдерживаемый «дескриптор» по каналу связи IPC дочернему процессу. Видеть subprocess.send()
а также process.send()
для дополнительной информации.
ERR_INVALID_HTTP_TOKEN
¶
Предоставлен недопустимый токен HTTP.
ERR_INVALID_IP_ADDRESS
¶
IP-адрес недействителен.
ERR_INVALID_MODULE
¶
Была сделана попытка загрузить несуществующий или недействительный модуль.
ERR_INVALID_MODULE_SPECIFIER
¶
Строка импортированного модуля является недопустимым URL-адресом, именем пакета или указателем подпути пакета.
ERR_INVALID_PACKAGE_CONFIG
¶
Недействительный package.json
файл не прошел синтаксический анализ.
ERR_INVALID_PACKAGE_TARGET
¶
В package.json
"exports"
Поле содержит недопустимое значение сопоставления цели для попытки разрешения модуля.
ERR_INVALID_PERFORMANCE_MARK
¶
При использовании Performance Timing API (perf_hooks
), отметка о производительности недействительна.
ERR_INVALID_PROTOCOL
¶
Недействительный options.protocol
был передан http.request()
.
ERR_INVALID_REPL_EVAL_CONFIG
¶
Оба breakEvalOnSigint
а также eval
параметры были установлены в REPL
config, который не поддерживается.
ERR_INVALID_REPL_INPUT
¶
Вход не может использоваться в REPL
. Условия, при которых используется эта ошибка, описаны в REPL
документация.
ERR_INVALID_RETURN_PROPERTY
¶
Выбрасывается в случае, если параметр функции не предоставляет допустимое значение для одного из свойств возвращаемого объекта при выполнении.
ERR_INVALID_RETURN_PROPERTY_VALUE
¶
Выбрасывается в случае, если параметр функции не предоставляет тип ожидаемого значения для одного из свойств возвращаемого объекта при выполнении.
ERR_INVALID_RETURN_VALUE
¶
Вызывается в случае, если опция функции не возвращает ожидаемый тип значения при выполнении, например, когда ожидается, что функция вернет обещание.
ERR_INVALID_STATE
¶
Указывает, что операция не может быть завершена из-за недопустимого состояния. Например, объект может быть уже уничтожен или может выполнять другую операцию.
ERR_INVALID_SYNC_FORK_INPUT
¶
А Buffer
, TypedArray
, DataView
или string
был предоставлен как вход stdio для асинхронной вилки. См. Документацию по child_process
модуль для получения дополнительной информации.
ERR_INVALID_THIS
¶
Функция API Node.js была вызвана с несовместимым this
ценить.
const urlSearchParams = new URLSearchParams(
'foo=bar&baz=new'
);
const buf = Buffer.alloc(1);
urlSearchParams.has.call(buf, 'foo');
// Throws a TypeError with code 'ERR_INVALID_THIS'
ERR_INVALID_TRANSFER_OBJECT
¶
Недопустимый объект передачи был передан в postMessage()
.
ERR_INVALID_TUPLE
¶
Элемент в iterable
предоставлен WHATWG URLSearchParams
конструктор не представлял [name, value]
кортеж — то есть, если элемент не повторяется или не состоит ровно из двух элементов.
ERR_INVALID_URI
¶
Передан неверный URI.
ERR_INVALID_URL
¶
Недействительный URL был передан в WHATWG URL
конструктор или наследие url.parse()
быть разобранным. Выброшенный объект ошибки обычно имеет дополнительное свойство 'input'
который содержит URL-адрес, который не удалось проанализировать.
ERR_INVALID_URL_SCHEME
¶
Была сделана попытка использовать URL несовместимой схемы (протокола) для определенной цели. Он используется только в WHATWG URL API поддержка в fs
модуль (который принимает только URL-адреса с 'file'
схема), но может использоваться и в других API Node.js в будущем.
ERR_IPC_CHANNEL_CLOSED
¶
Была сделана попытка использовать канал связи IPC, который уже был закрыт.
ERR_IPC_DISCONNECTED
¶
Была сделана попытка отключить уже отключенный канал связи IPC. См. Документацию по child_process
модуль для получения дополнительной информации.
ERR_IPC_ONE_PIPE
¶
Была предпринята попытка создать дочерний процесс Node.js, использующий более одного канала связи IPC. См. Документацию по child_process
модуль для получения дополнительной информации.
ERR_IPC_SYNC_FORK
¶
Была предпринята попытка открыть канал связи IPC с помощью синхронно разветвленного процесса Node.js. См. Документацию по child_process
модуль для получения дополнительной информации.
ERR_MANIFEST_ASSERT_INTEGRITY
¶
Была предпринята попытка загрузить ресурс, но ресурс не соответствовал целостности, определенной в манифесте политики. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_DEPENDENCY_MISSING
¶
Была предпринята попытка загрузить ресурс, но ресурс не был указан как зависимость от расположения, в котором его пытались загрузить. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_INTEGRITY_MISMATCH
¶
Была сделана попытка загрузить манифест политики, но в манифесте было несколько записей для ресурса, которые не совпадали друг с другом. Обновите записи манифеста, чтобы они соответствовали, чтобы устранить эту ошибку. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_INVALID_RESOURCE_FIELD
¶
Ресурс манифеста политики имел недопустимое значение для одного из полей. Обновите запись манифеста, чтобы она соответствовала, чтобы устранить эту ошибку. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_INVALID_SPECIFIER
¶
Ресурс манифеста политики имел недопустимое значение для одного из сопоставлений зависимостей. Обновите запись манифеста, чтобы она соответствовала разрешению этой ошибки. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_PARSE_POLICY
¶
Была предпринята попытка загрузить манифест политики, но не удалось проанализировать манифест. Документацию для политика манифесты для получения дополнительной информации.
ERR_MANIFEST_TDZ
¶
Была предпринята попытка чтения из манифеста политики, но инициализация манифеста еще не произошла. Вероятно, это ошибка в Node.js.
ERR_MANIFEST_UNKNOWN_ONERROR
¶
Манифест политики был загружен, но для его поведения «onerror» было неизвестно значение. Документацию для политика манифесты для получения дополнительной информации.
ERR_MEMORY_ALLOCATION_FAILED
¶
Была предпринята попытка выделить память (обычно на уровне C ++), но она не удалась.
ERR_MESSAGE_TARGET_CONTEXT_UNAVAILABLE
¶
Сообщение отправлено MessagePort
не удалось десериализовать в целевой vm Context
. Не все объекты Node.js могут быть успешно созданы в любом контексте в настоящее время, и попытки передать их с помощью postMessage()
в этом случае может выйти из строя принимающая сторона.
ERR_METHOD_NOT_IMPLEMENTED
¶
Метод требуется, но не реализован.
ERR_MISSING_ARGS
¶
Не был передан обязательный аргумент API Node.js. Это используется только для строгого соответствия спецификации API (которая в некоторых случаях может принимать func(undefined)
но нет func()
). В большинстве собственных API-интерфейсов Node.js func(undefined)
а также func()
рассматриваются одинаково, а ERR_INVALID_ARG_TYPE
вместо этого можно использовать код ошибки.
ERR_MISSING_OPTION
¶
Для API-интерфейсов, которые принимают объекты параметров, некоторые параметры могут быть обязательными. Этот код выдается, если отсутствует необходимая опция.
ERR_MISSING_PASSPHRASE
¶
Была сделана попытка прочитать зашифрованный ключ без указания ключевой фразы.
ERR_MISSING_PLATFORM_FOR_WORKER
¶
Платформа V8, используемая этим экземпляром Node.js, не поддерживает создание рабочих. Это вызвано отсутствием поддержки Embedder для Workers. В частности, эта ошибка не возникает при использовании стандартных сборок Node.js.
ERR_MISSING_TRANSFERABLE_IN_TRANSFER_LIST
¶
Объект, который должен быть явно указан в transferList
аргумент находится в объекте, переданном в postMessage()
звоните, но не указано в transferList
для этого звонка. Обычно это MessagePort
.
В версиях Node.js до v15.0.0 использованный здесь код ошибки был ERR_MISSING_MESSAGE_PORT_IN_TRANSFER_LIST
. Однако набор переносимых типов объектов был расширен, чтобы охватить больше типов, чем MessagePort
.
ERR_MODULE_NOT_FOUND
¶
Стабильность: 1 — экспериментальная
An Модуль ES не может быть решен.
ERR_MULTIPLE_CALLBACK
¶
Обратный звонок был вызван более одного раза.
Обратный вызов почти всегда предназначен для однократного вызова, поскольку запрос может быть выполнен или отклонен, но не оба одновременно. Последнее станет возможным, если вызвать обратный вызов более одного раза.
ERR_NAPI_CONS_FUNCTION
¶
При использовании Node-API
, переданный конструктор не является функцией.
ERR_NAPI_INVALID_DATAVIEW_ARGS
¶
Во время звонка napi_create_dataview()
, данный offset
находился за пределами окна просмотра данных или offset + length
был больше, чем длина заданного buffer
.
ERR_NAPI_INVALID_TYPEDARRAY_ALIGNMENT
¶
Во время звонка napi_create_typedarray()
предоставленные offset
не был кратен размеру элемента.
ERR_NAPI_INVALID_TYPEDARRAY_LENGTH
¶
Во время звонка napi_create_typedarray()
, (length * size_of_element) + byte_offset
был больше, чем длина заданного buffer
.
ERR_NAPI_TSFN_CALL_JS
¶
Произошла ошибка при вызове части JavaScript поточно-ориентированной функции.
ERR_NAPI_TSFN_GET_UNDEFINED
¶
Произошла ошибка при попытке получить код JavaScript. undefined
ценить.
ERR_NAPI_TSFN_START_IDLE_LOOP
¶
В основном потоке значения удаляются из очереди, связанной с поточно-ориентированной функцией, в цикле ожидания. Эта ошибка указывает на то, что произошла ошибка при попытке запустить цикл.
ERR_NAPI_TSFN_STOP_IDLE_LOOP
¶
Если в очереди больше не осталось элементов, цикл простоя должен быть приостановлен. Эта ошибка указывает на то, что не удалось остановить цикл холостого хода.
ERR_NO_CRYPTO
¶
Была предпринята попытка использовать функции шифрования, пока Node.js не был скомпилирован с поддержкой шифрования OpenSSL.
ERR_NO_ICU
¶
Была предпринята попытка использовать функции, требующие ICU, но Node.js не был скомпилирован с поддержкой ICU.
ERR_NON_CONTEXT_AWARE_DISABLED
¶
Родной аддон, не зависящий от контекста, был загружен в процессе, который их запрещает.
ERR_OUT_OF_RANGE
¶
Заданное значение выходит за пределы допустимого диапазона.
ERR_PACKAGE_IMPORT_NOT_DEFINED
¶
В package.json
"imports"
поле не определяет заданное отображение спецификатора внутреннего пакета.
ERR_PACKAGE_PATH_NOT_EXPORTED
¶
В package.json
"exports"
не экспортирует запрошенный подпуть. Поскольку экспорт инкапсулирован, частные внутренние модули, которые не экспортируются, не могут быть импортированы через разрешение пакета, если не используется абсолютный URL-адрес.
ERR_PERFORMANCE_INVALID_TIMESTAMP
¶
Для отметки производительности или показателя было предоставлено недопустимое значение метки времени.
ERR_PERFORMANCE_MEASURE_INVALID_OPTIONS
¶
Предусмотрены недопустимые варианты измерения производительности.
ERR_PROTO_ACCESS
¶
Доступ Object.prototype.__proto__
было запрещено использовать --disable-proto=throw
. Object.getPrototypeOf
а также Object.setPrototypeOf
следует использовать для получения и установки прототипа объекта.
ERR_REQUIRE_ESM
¶
Стабильность: 1 — экспериментальная
Была сделана попытка require()
ан Модуль ES.
ERR_SCRIPT_EXECUTION_INTERRUPTED
¶
Выполнение скрипта было прервано SIGINT
(Например, Ctrl+C был нажат.)
ERR_SCRIPT_EXECUTION_TIMEOUT
¶
Истекло время выполнения сценария, возможно, из-за ошибок в выполняемом сценарии.
ERR_SERVER_ALREADY_LISTEN
¶
В server.listen()
метод был вызван в то время как net.Server
уже слушал. Это относится ко всем экземплярам net.Server
, включая HTTP, HTTPS и HTTP / 2 Server
экземпляры.
ERR_SERVER_NOT_RUNNING
¶
В server.close()
метод был вызван, когда net.Server
не работал. Это относится ко всем экземплярам net.Server
, включая HTTP, HTTPS и HTTP / 2 Server
экземпляры.
ERR_SOCKET_ALREADY_BOUND
¶
Была сделана попытка привязать уже связанный сокет.
ERR_SOCKET_BAD_BUFFER_SIZE
¶
Был передан недопустимый (отрицательный) размер для recvBufferSize
или sendBufferSize
варианты в dgram.createSocket()
.
ERR_SOCKET_BAD_PORT
¶
Функция API, ожидающая порта> = 0 и <65536, получила недопустимое значение.
ERR_SOCKET_BAD_TYPE
¶
Функция API, ожидающая типа сокета (udp4
или udp6
) получил недопустимое значение.
ERR_SOCKET_BUFFER_SIZE
¶
При использовании dgram.createSocket()
, размер получения или отправки Buffer
не может быть определено.
ERR_SOCKET_CLOSED
¶
Была сделана попытка работать с уже закрытым сокетом.
ERR_SOCKET_DGRAM_IS_CONNECTED
¶
А dgram.connect()
вызов был сделан на уже подключенном сокете.
ERR_SOCKET_DGRAM_NOT_CONNECTED
¶
А dgram.disconnect()
или dgram.remoteAddress()
звонок был сделан на отключенной розетке.
ERR_SOCKET_DGRAM_NOT_RUNNING
¶
Был сделан вызов, но подсистема UDP не работала.
ERR_SRI_PARSE
¶
Строка была предоставлена для проверки целостности подресурса, но не может быть проанализирована. Проверьте формат атрибутов целостности, посмотрев на Спецификация целостности подресурсов.
ERR_STREAM_ALREADY_FINISHED
¶
Был вызван метод потока, который не может быть завершен, поскольку поток был завершен.
ERR_STREAM_CANNOT_PIPE
¶
Была сделана попытка позвонить stream.pipe()
на Writable
транслировать.
ERR_STREAM_DESTROYED
¶
Был вызван метод потока, который не может быть завершен, поскольку поток был уничтожен с использованием stream.destroy()
.
ERR_STREAM_NULL_VALUES
¶
Была сделана попытка позвонить stream.write()
с null
кусок.
ERR_STREAM_PREMATURE_CLOSE
¶
Ошибка, возвращенная stream.finished()
а также stream.pipeline()
, когда поток или конвейер завершаются некорректно, без явной ошибки.
ERR_STREAM_PUSH_AFTER_EOF
¶
Была сделана попытка позвонить stream.push()
после null
(EOF) был отправлен в поток.
ERR_STREAM_UNSHIFT_AFTER_END_EVENT
¶
Была сделана попытка позвонить stream.unshift()
после 'end'
событие было отправлено.
ERR_STREAM_WRAP
¶
Предотвращает прерывание, если строковый декодер был установлен на Socket или если декодер находится в objectMode
.
const Socket = require('net').Socket;
const instance = new Socket();
instance.setEncoding('utf8');
ERR_STREAM_WRITE_AFTER_END
¶
Была сделана попытка позвонить stream.write()
после stream.end()
был вызван.
ERR_STRING_TOO_LONG
¶
Была сделана попытка создать строку длиннее максимально допустимой.
ERR_SYNTHETIC
¶
Искусственный объект ошибки, используемый для захвата стека вызовов для диагностических отчетов.
ERR_SYSTEM_ERROR
¶
В процессе Node.js произошла неопределенная или неспецифическая системная ошибка. Объект ошибки будет иметь err.info
свойство объекта с дополнительной информацией.
ERR_TLS_CERT_ALTNAME_INVALID
¶
При использовании TLS имя хоста / IP-адрес однорангового узла не соответствует ни одному из subjectAltNames
в его сертификате.
ERR_TLS_DH_PARAM_SIZE
¶
При использовании TLS параметр, предлагаемый для алгоритма Диффи-Хеллмана (DH
) протокол согласования ключей слишком мал. По умолчанию длина ключа должна быть больше или равна 1024 битам, чтобы избежать уязвимостей, хотя настоятельно рекомендуется использовать 2048 бит или больше для большей безопасности.
ERR_TLS_HANDSHAKE_TIMEOUT
¶
Время ожидания подтверждения TLS / SSL истекло. В этом случае сервер также должен прервать соединение.
ERR_TLS_INVALID_CONTEXT
¶
Контекст должен быть SecureContext
.
ERR_TLS_INVALID_PROTOCOL_METHOD
¶
Указанный secureProtocol
метод недействителен. Он либо неизвестен, либо отключен, потому что небезопасен.
ERR_TLS_INVALID_PROTOCOL_VERSION
¶
Допустимые версии протокола TLS: 'TLSv1'
, 'TLSv1.1'
, или 'TLSv1.2'
.
ERR_TLS_INVALID_STATE
¶
Сокет TLS должен быть подключен и надежно установлен. Перед продолжением убедитесь, что «безопасное» событие запущено.
ERR_TLS_PROTOCOL_VERSION_CONFLICT
¶
Попытка установить протокол TLS minVersion
или maxVersion
конфликтует с попыткой установить secureProtocol
явно. Используйте тот или иной механизм.
ERR_TLS_PSK_SET_IDENTIY_HINT_FAILED
¶
Не удалось установить подсказку идентификатора PSK. Подсказка может быть слишком длинной.
ERR_TLS_RENEGOTIATION_DISABLED
¶
Была сделана попытка повторно согласовать TLS на экземпляре сокета с отключенным TLS.
ERR_TLS_REQUIRED_SERVER_NAME
¶
При использовании TLS server.addContext()
был вызван без указания имени хоста в первом параметре.
ERR_TLS_SESSION_ATTACK
¶
Обнаружено чрезмерное количество повторных согласований TLS, что является потенциальным вектором атак типа «отказ в обслуживании».
ERR_TLS_SNI_FROM_SERVER
¶
Была предпринята попытка выдать указание имени сервера из сокета на стороне сервера TLS, который действителен только для клиента.
ERR_TRACE_EVENTS_CATEGORY_REQUIRED
¶
В trace_events.createTracing()
требуется по крайней мере одна категория событий трассировки.
ERR_TRACE_EVENTS_UNAVAILABLE
¶
В trace_events
модуль не может быть загружен, потому что Node.js был скомпилирован с --without-v8-platform
флаг.
ERR_TRANSFORM_ALREADY_TRANSFORMING
¶
А Transform
поток завершился, пока он все еще преобразовывался.
ERR_TRANSFORM_WITH_LENGTH_0
¶
А Transform
поток закончился с данными, все еще находящимися в буфере записи.
ERR_TTY_INIT_FAILED
¶
Инициализация TTY не удалась из-за системной ошибки.
ERR_UNAVAILABLE_DURING_EXIT
¶
Функция была вызвана в process.on('exit')
обработчик, который не должен вызываться внутри process.on('exit')
обработчик.
ERR_UNCAUGHT_EXCEPTION_CAPTURE_ALREADY_SET
¶
process.setUncaughtExceptionCaptureCallback()
был вызван дважды, без предварительного сброса обратного вызова на null
.
Эта ошибка предназначена для предотвращения случайной перезаписи обратного вызова, зарегистрированного из другого модуля.
ERR_UNESCAPED_CHARACTERS
¶
Получена строка, содержащая неэкранированные символы.
ERR_UNHANDLED_ERROR
¶
Произошла необработанная ошибка (например, когда 'error'
событие испускается EventEmitter
но 'error'
обработчик не зарегистрирован).
ERR_UNKNOWN_BUILTIN_MODULE
¶
Используется для определения определенного вида внутренней ошибки Node.js, которая обычно не должна запускаться кодом пользователя. Экземпляры этой ошибки указывают на внутреннюю ошибку в самом двоичном файле Node.js.
ERR_UNKNOWN_CREDENTIAL
¶
Был передан несуществующий идентификатор группы или пользователя Unix.
ERR_UNKNOWN_ENCODING
¶
В API передан неверный или неизвестный параметр кодировки.
ERR_UNKNOWN_FILE_EXTENSION
¶
Стабильность: 1 — экспериментальная
Была сделана попытка загрузить модуль с неизвестным или неподдерживаемым расширением файла.
ERR_UNKNOWN_MODULE_FORMAT
¶
Стабильность: 1 — экспериментальная
Была сделана попытка загрузить модуль с неизвестным или неподдерживаемым форматом.
ERR_UNKNOWN_SIGNAL
¶
Неверный или неизвестный сигнал процесса был передан API, ожидающему действительного сигнала (например, subprocess.kill()
).
ERR_UNSUPPORTED_DIR_IMPORT
¶
import
URL-адрес каталога не поддерживается. Вместо, Самостоятельная ссылка на пакет, используя его имя а также определить настраиваемый подпуть в "exports"
поле package.json
файл.
import './'; // unsupported
import './index.js'; // supported
import 'package-name'; // supported
ERR_UNSUPPORTED_ESM_URL_SCHEME
¶
import
со схемами URL, отличными от file
а также data
не поддерживается.
ERR_VALID_PERFORMANCE_ENTRY_TYPE
¶
При использовании Performance Timing API (perf_hooks
) допустимые типы записей производительности не найдены.
ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING
¶
Обратный вызов динамического импорта не указан.
ERR_VM_MODULE_ALREADY_LINKED
¶
Модуль, который пытались связать, не подходит для связывания по одной из следующих причин:
- Он уже был связан (
linkingStatus
является'linked'
) - Это связано (
linkingStatus
является'linking'
) - Не удалось установить связь для этого модуля (
linkingStatus
является'errored'
)
ERR_VM_MODULE_CACHED_DATA_REJECTED
¶
В cachedData
Параметр, переданный конструктору модуля, недопустим.
ERR_VM_MODULE_CANNOT_CREATE_CACHED_DATA
¶
Кэшированные данные не могут быть созданы для модулей, которые уже были оценены.
ERR_VM_MODULE_DIFFERENT_CONTEXT
¶
Модуль, возвращаемый функцией компоновщика, находится в другом контексте, чем родительский модуль. Связанные модули должны иметь общий контекст.
ERR_VM_MODULE_LINKING_ERRORED
¶
Функция компоновщика вернула модуль, для которого не удалось выполнить связывание.
ERR_VM_MODULE_LINK_FAILURE
¶
Модуль не удалось связать из-за сбоя.
ERR_VM_MODULE_NOT_MODULE
¶
Выполненное значение обещания связывания не является vm.Module
объект.
ERR_VM_MODULE_STATUS
¶
Текущий статус модуля не позволяет выполнить эту операцию. Конкретный смысл ошибки зависит от конкретной функции.
ERR_WASI_ALREADY_STARTED
¶
Экземпляр WASI уже запущен.
ERR_WASI_NOT_STARTED
¶
Экземпляр WASI не запущен.
ERR_WORKER_INIT_FAILED
¶
В Worker
Ошибка инициализации.
ERR_WORKER_INVALID_EXEC_ARGV
¶
В execArgv
вариант передан в Worker
конструктор содержит недопустимые флаги.
ERR_WORKER_NOT_RUNNING
¶
Операция завершилась неудачно, потому что Worker
экземпляр в настоящее время не запущен.
ERR_WORKER_OUT_OF_MEMORY
¶
В Worker
Экземпляр остановлен, поскольку достиг предела памяти.
ERR_WORKER_PATH
¶
Путь для основного скрипта рабочего не является ни абсолютным, ни относительным путем, начинающимся с ./
или ../
.
ERR_WORKER_UNSERIALIZABLE_ERROR
¶
Все попытки сериализации неперехваченного исключения из рабочего потока завершились неудачно.
ERR_WORKER_UNSUPPORTED_OPERATION
¶
Запрошенная функциональность не поддерживается в рабочих потоках.
ERR_ZLIB_INITIALIZATION_FAILED
¶
Создание zlib
сбой объекта из-за неправильной конфигурации.
Получено слишком много данных заголовка HTTP. Для защиты от злонамеренных или неправильно настроенных клиентов, если получено более 8 КБ данных HTTP-заголовка, анализ HTTP будет прерван без создания объекта запроса или ответа, и Error
с этим кодом будет выпущен.
HPE_UNEXPECTED_CONTENT_LENGTH
¶
Сервер отправляет как Content-Length
заголовок и Transfer-Encoding: chunked
.
Transfer-Encoding: chunked
позволяет серверу поддерживать постоянное соединение HTTP для динамически генерируемого контента. В этом случае Content-Length
Заголовок HTTP использовать нельзя.
Использовать Content-Length
или Transfer-Encoding: chunked
.
MODULE_NOT_FOUND
¶
Не удалось разрешить файл модуля при попытке require()
или import
операция.
Устаревшие коды ошибок Node.js¶
Стабильность: 0 — Не рекомендуется. Эти коды ошибок либо несовместимы, либо были удалены.
ERR_CANNOT_TRANSFER_OBJECT
¶
Значение, переданное в postMessage()
содержит объект, который не поддерживается для передачи.
ERR_CRYPTO_HASH_DIGEST_NO_UTF16
¶
Кодировка UTF-16 использовалась с hash.digest()
. В то время как hash.digest()
метод позволяет encoding
аргумент, который должен быть передан, в результате чего метод возвращает строку, а не Buffer
, кодировка UTF-16 (например, ucs
или utf16le
) не поддерживается.
ERR_HTTP2_FRAME_ERROR
¶
Используется при сбое отправки отдельного кадра в сеансе HTTP / 2.
Используется, когда ожидается объект заголовков HTTP / 2.
Используется, когда в сообщении HTTP / 2 отсутствует требуемый заголовок.
Информационные заголовки HTTP / 2 должны отправляться только прежний позвонить в Http2Stream.prototype.respond()
метод.
ERR_HTTP2_STREAM_CLOSED
¶
Используется, когда действие было выполнено над уже закрытым потоком HTTP / 2.
ERR_HTTP_INVALID_CHAR
¶
Используется, когда в сообщении статуса ответа HTTP (фраза причины) обнаружен недопустимый символ.
ERR_INDEX_OUT_OF_RANGE
¶
Данный индекс был вне допустимого диапазона (например, отрицательные смещения).
ERR_INVALID_OPT_VALUE
¶
В объект опций было передано недопустимое или неожиданное значение.
ERR_INVALID_OPT_VALUE_ENCODING
¶
Передана неверная или неизвестная кодировка файла.
ERR_MISSING_MESSAGE_PORT_IN_TRANSFER_LIST
¶
Этот код ошибки был заменен на ERR_MISSING_TRANSFERABLE_IN_TRANSFER_LIST
в Node.js v15.0.0, потому что он больше не точен, поскольку теперь существуют и другие типы переносимых объектов.
ERR_NAPI_CONS_PROTOTYPE_OBJECT
¶
Используется Node-API
когда Constructor.prototype
не объект.
ERR_NO_LONGER_SUPPORTED
¶
API Node.js был вызван неподдерживаемым способом, например Buffer.write(string, encoding, offset[, length])
.
ERR_OPERATION_FAILED
¶
Не удалось выполнить операцию. Обычно это используется, чтобы сигнализировать об общем сбое асинхронной операции.
ERR_OUTOFMEMORY
¶
Обычно используется для определения того, что операция вызвала нехватку памяти.
ERR_PARSE_HISTORY_DATA
¶
В repl
модулю не удалось проанализировать данные из файла истории REPL.
ERR_SOCKET_CANNOT_SEND
¶
Данные не могут быть отправлены через сокет.
ERR_STDERR_CLOSE
¶
Была сделана попытка закрыть process.stderr
транслировать. По замыслу Node.js не позволяет stdout
или stderr
потоки должны быть закрыты кодом пользователя.
ERR_STDOUT_CLOSE
¶
Была сделана попытка закрыть process.stdout
транслировать. По замыслу Node.js не позволяет stdout
или stderr
потоки должны быть закрыты кодом пользователя.
ERR_STREAM_READ_NOT_IMPLEMENTED
¶
Используется, когда делается попытка использовать читаемый поток, который не реализован readable._read()
.
ERR_TLS_RENEGOTIATION_FAILED
¶
Используется, когда запрос на повторное согласование TLS завершился ошибкой неспецифическим образом.
ERR_TRANSFERRING_EXTERNALIZED_SHAREDARRAYBUFFER
¶
А SharedArrayBuffer
чья память не управляется механизмом JavaScript или Node.js. во время сериализации. Такой SharedArrayBuffer
не может быть сериализован.
Это может произойти только тогда, когда нативные аддоны создают SharedArrayBuffer
s в «внешнем» режиме или поместите существующий SharedArrayBuffer
во внешний режим.
ERR_UNKNOWN_STDIN_TYPE
¶
Была предпринята попытка запустить процесс Node.js с неизвестным stdin
тип файла. Эта ошибка обычно указывает на ошибку в самом Node.js, хотя пользовательский код может вызвать ее.
ERR_UNKNOWN_STREAM_TYPE
¶
Была предпринята попытка запустить процесс Node.js с неизвестным stdout
или stderr
тип файла. Эта ошибка обычно указывает на ошибку в самом Node.js, хотя пользовательский код может вызвать ее.
ERR_V8BREAKITERATOR
¶
V8 BreakIterator
API использовался, но не установлен полный набор данных ICU.
ERR_VALUE_OUT_OF_RANGE
¶
Используется, когда заданное значение выходит за пределы допустимого диапазона.
ERR_VM_MODULE_NOT_LINKED
¶
Перед созданием экземпляра модуль должен быть успешно связан.
ERR_WORKER_UNSUPPORTED_EXTENSION
¶
Имя пути, используемое для основного сценария рабочего, имеет неизвестное расширение файла.
ERR_ZLIB_BINDING_CLOSED
¶
Используется, когда делается попытка использовать zlib
объект после того, как он уже был закрыт.
ERR_CPU_USAGE
¶
Родной звонок от process.cpuUsage
не может быть обработано.
Ошибки — это хорошо. Автор материала, перевод которого мы сегодня публикуем, говорит, что уверен в том, что эта идея известна всем. На первый взгляд ошибки кажутся чем-то страшным. Им могут сопутствовать какие-то потери. Ошибка, сделанная на публике, вредит авторитету того, кто её совершил. Но, совершая ошибки, мы на них учимся, а значит, попадая в следующий раз в ситуацию, в которой раньше вели себя неправильно, делаем всё как нужно.
Выше мы говорили об ошибках, которые люди совершают в обычной жизни. Ошибки в программировании — это нечто иное. Сообщения об ошибках помогают нам улучшать код, они позволяют сообщать пользователям наших проектов о том, что что-то пошло не так, и, возможно, рассказывают пользователям о том, как нужно вести себя для того, чтобы ошибок больше не возникало.
Этот материал, посвящённый обработке ошибок в JavaScript, разбит на три части. Сначала мы сделаем общий обзор системы обработки ошибок в JavaScript и поговорим об объектах ошибок. После этого мы поищем ответ на вопрос о том, что делать с ошибками, возникающими в серверном коде (в частности, при использовании связки Node.js + Express.js). Далее — обсудим обработку ошибок в React.js. Фреймворки, которые будут здесь рассматриваться, выбраны по причине их огромной популярности. Однако рассматриваемые здесь принципы работы с ошибками универсальны, поэтому вы, даже если не пользуетесь Express и React, без труда сможете применить то, что узнали, к тем инструментам, с которыми работаете.
Код демонстрационного проекта, используемого в данном материале, можно найти в этом репозитории.
1. Ошибки в JavaScript и универсальные способы работы с ними
Если в вашем коде что-то пошло не так, вы можете воспользоваться следующей конструкцией.
throw new Error('something went wrong')
В ходе выполнения этой команды будет создан экземпляр объекта Error и будет сгенерировано (или, как говорят, «выброшено») исключение с этим объектом. Инструкция throw может генерировать исключения, содержащие произвольные выражения. При этом выполнение скрипта остановится в том случае, если не были предприняты меры по обработке ошибки.
Начинающие JS-программисты обычно не используют инструкцию throw
. Они, как правило, сталкиваются с исключениями, выдаваемыми либо средой выполнения языка, либо сторонними библиотеками. Когда это происходит — в консоль попадает нечто вроде ReferenceError: fs is not defined
и выполнение программы останавливается.
▍Объект Error
У экземпляров объекта Error
есть несколько свойств, которыми мы можем пользоваться. Первое интересующее нас свойство — message
. Именно сюда попадает та строка, которую можно передать конструктору ошибки в качестве аргумента. Например, ниже показано создание экземпляра объекта Error
и вывод в консоль переданной конструктором строки через обращение к его свойству message
.
const myError = new Error('please improve your code')
console.log(myError.message) // please improve your code
Второе свойство объекта, очень важное, представляет собой трассировку стека ошибки. Это — свойство stack
. Обратившись к нему можно просмотреть стек вызовов (историю ошибки), который показывает последовательность операций, приведшую к неправильной работе программы. В частности, это позволяет понять — в каком именно файле содержится сбойный код, и увидеть, какая последовательность вызовов функций привела к ошибке. Вот пример того, что можно увидеть, обратившись к свойству stack
.
Error: please improve your code
at Object.<anonymous> (/Users/gisderdube/Documents/_projects/hacking.nosync/error-handling/src/general.js:1:79)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
at startup (internal/bootstrap/node.js:266:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)
Здесь, в верхней части, находится сообщение об ошибке, затем следует указание на тот участок кода, выполнение которого вызвало ошибку, потом описывается то место, откуда был вызван этот сбойный участок. Это продолжается до самого «дальнего» по отношению к ошибке фрагмента кода.
▍Генерирование и обработка ошибок
Создание экземпляра объекта Error
, то есть, выполнение команды вида new Error()
, ни к каким особым последствиям не приводит. Интересные вещи начинают происходить после применения оператора throw
, который генерирует ошибку. Как уже было сказано, если такую ошибку не обработать, выполнение скрипта остановится. При этом нет никакой разницы — был ли оператор throw
использован самим программистом, произошла ли ошибка в некоей библиотеке или в среде выполнения языка (в браузере или в Node.js). Поговорим о различных сценариях обработки ошибок.
▍Конструкция try…catch
Блок try...catch
представляет собой самый простой способ обработки ошибок, о котором часто забывают. В наши дни, правда, он используется гораздо интенсивнее чем раньше, благодаря тому, что его можно применять для обработки ошибок в конструкциях async/await
.
Этот блок можно использовать для обработки любых ошибок, происходящих в синхронном коде. Рассмотрим пример.
const a = 5
try {
console.log(b) // переменная b не объявлена - возникает ошибка
} catch (err) {
console.error(err) // в консоль попадает сообщение об ошибке и стек ошибки
}
console.log(a) // выполнение скрипта не останавливается, данная команда выполняется
Если бы в этом примере мы не заключили бы сбойную команду console.log(b)
в блок try...catch
, то выполнение скрипта было бы остановлено.
▍Блок finally
Иногда случается так, что некий код нужно выполнить независимо от того, произошла ошибка или нет. Для этого можно, в конструкции try...catch
, использовать третий, необязательный, блок — finally
. Часто его использование эквивалентно некоему коду, который идёт сразу после try...catch
, но в некоторых ситуациях он может пригодиться. Вот пример его использования.
const a = 5
try {
console.log(b) // переменная b не объявлена - возникает ошибка
} catch (err) {
console.error(err) // в консоль попадает сообщение об ошибке и стек ошибки
} finally {
console.log(a) // этот код будет выполнен в любом случае
}
▍Асинхронные механизмы — коллбэки
Программируя на JavaScript всегда стоит обращать внимание на участки кода, выполняющиеся асинхронно. Если у вас имеется асинхронная функция и в ней возникает ошибка, скрипт продолжит выполняться. Когда асинхронные механизмы в JS реализуются с использованием коллбэков (кстати, делать так не рекомендуется), соответствующий коллбэк (функция обратного вызова) обычно получает два параметра. Это нечто вроде параметра err
, который может содержать ошибку, и result
— с результатами выполнения асинхронной операции. Выглядит это примерно так:
myAsyncFunc(someInput, (err, result) => {
if(err) return console.error(err) // порядок работы с объектом ошибки мы рассмотрим позже
console.log(result)
})
Если в коллбэк попадает ошибка, она видна там в виде параметра err
. В противном случае в этот параметр попадёт значение undefined
или null
. Если оказалось, что в err
что-то есть, важно отреагировать на это, либо так как в нашем примере, воспользовавшись командой return
, либо воспользовавшись конструкцией if...else
и поместив в блок else
команды для работы с результатом выполнения асинхронной операции. Речь идёт о том, чтобы, в том случае, если произошла ошибка, исключить возможность работы с результатом, параметром result
, который в таком случае может иметь значение undefined
. Работа с таким значением, если предполагается, например, что оно содержит объект, сама может вызвать ошибку. Скажем, это произойдёт при попытке использовать конструкцию result.data
или подобную ей.
▍Асинхронные механизмы — промисы
Для выполнения асинхронных операций в JavaScript лучше использовать не коллбэки а промисы. Тут, в дополнение к улучшенной читабельности кода, имеются и более совершенные механизмы обработки ошибок. А именно, возиться с объектом ошибки, который может попасть в функцию обратного вызова, при использовании промисов не нужно. Здесь для этой цели предусмотрен специальный блок catch
. Он перехватывает все ошибки, произошедшие в промисах, которые находятся до него, или все ошибки, которые произошли в коде после предыдущего блока catch
. Обратите внимание на то, что если в промисе произошла ошибка, для обработки которой нет блока catch
, это не остановит выполнение скрипта, но сообщение об ошибке будет не особенно удобочитаемым.
(node:7741) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: something went wrong
(node:7741) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. */
В результате можно порекомендовать всегда, при работе с промисами, использовать блок catch
. Взглянем на пример.
Promise.resolve(1)
.then(res => {
console.log(res) // 1
throw new Error('something went wrong')
return Promise.resolve(2)
})
.then(res => {
console.log(res) // этот блок выполнен не будет
})
.catch(err => {
console.error(err) // о том, что делать с этой ошибкой, поговорим позже
return Promise.resolve(3)
})
.then(res => {
console.log(res) // 3
})
.catch(err => {
// этот блок тут на тот случай, если в предыдущем блоке возникнет какая-нибудь ошибка
console.error(err)
})
▍Асинхронные механизмы и try…catch
После того, как в JavaScript появилась конструкция async/await
, мы вернулись к классическому способу обработки ошибок — к try...catch...finally
. Обрабатывать ошибки при таком подходе оказывается очень легко и удобно. Рассмотрим пример.
;(async function() {
try {
await someFuncThatThrowsAnError()
} catch (err) {
console.error(err) // об этом поговорим позже
}
console.log('Easy!') // будет выполнено
})()
При таком подходе ошибки в асинхронном коде обрабатываются так же, как в синхронном. В результате теперь, при необходимости, в одном блоке catch
можно обрабатывать более широкий диапазон ошибок.
2. Генерирование и обработка ошибок в серверном коде
Теперь, когда у нас есть инструменты для работы с ошибками, посмотрим на то, что мы можем с ними делать в реальных ситуациях. Генерирование и правильная обработка ошибок — это важнейший аспект серверного программирования. Существуют разные подходы к работе с ошибками. Здесь будет продемонстрирован подход с использованием собственного конструктора для экземпляров объекта Error
и кодов ошибок, которые удобно передавать во фронтенд или любым механизмам, использующим серверные API. Как структурирован бэкенд конкретного проекта — особого значения не имеет, так как при любом подходе можно использовать одни и те же идеи, касающиеся работы с ошибками.
В качестве серверного фреймворка, отвечающего за маршрутизацию, мы будем использовать Express.js. Подумаем о том, какая структура нам нужна для организации эффективной системы обработки ошибок. Итак, вот что нам нужно:
- Универсальная обработка ошибок — некий базовый механизм, подходящий для обработки любых ошибок, в ходе работы которого просто выдаётся сообщение наподобие
Something went wrong, please try again or contact us
, предлагающее пользователю попробовать выполнить операцию, давшую сбой, ещё раз или связаться с владельцем сервера. Эта система не отличается особой интеллектуальностью, но она, по крайней мере, способна сообщить пользователю о том, что что-то пошло не так. Подобное сообщение гораздо лучше, чем «бесконечная загрузка» или нечто подобное. - Обработка конкретных ошибок — механизм, позволяющий сообщить пользователю подробные сведения о причинах неправильного поведения системы и дать ему конкретные советы по борьбе с неполадкой. Например, это может касаться отсутствия неких важных данных в запросе, который пользователь отправляет на сервер, или в том, что в базе данных уже существует некая запись, которую он пытается добавить ещё раз, и так далее.
▍Разработка собственного конструктора объектов ошибок
Здесь мы воспользуемся стандартным классом Error
и расширим его. Пользоваться механизмами наследования в JavaScript — дело рискованное, но в данном случае эти механизмы оказываются весьма полезными. Зачем нам наследование? Дело в том, что нам, для того, чтобы код удобно было бы отлаживать, нужны сведения о трассировке стека ошибки. Расширяя стандартный класс Error
, мы, без дополнительных усилий, получаем возможности по трассировке стека. Мы добавляем в наш собственный объект ошибки два свойства. Первое — это свойство code
, доступ к которому можно будет получить с помощью конструкции вида err.code
. Второе — свойство status
. В него будет записываться код состояния HTTP, который планируется передавать клиентской части приложения.
Вот как выглядит класс CustomError
, код которого оформлен в виде модуля.
class CustomError extends Error {
constructor(code = 'GENERIC', status = 500, ...params) {
super(...params)
if (Error.captureStackTrace) {
Error.captureStackTrace(this, CustomError)
}
this.code = code
this.status = status
}
}
module.exports = CustomError
▍Маршрутизация
Теперь, когда наш объект ошибки готов к использованию, нужно настроить структуру маршрутов. Как было сказано выше, нам требуется реализовать унифицированный подход к обработке ошибок, позволяющий одинаково обрабатывать ошибки для всех маршрутов. По умолчанию фреймворк Express.js не вполне поддерживает такую схему работы. Дело в том, что все его маршруты инкапсулированы.
Для того чтобы справиться с этой проблемой, мы можем реализовать собственный обработчик маршрутов и определять логику маршрутов в виде обычных функций. Благодаря такому подходу, если функция маршрута (или любая другая функция) выбрасывает ошибку, она попадёт в обработчик маршрутов, который затем может передать её клиентской части приложения. При возникновении ошибки на сервере мы планируем передавать её во фронтенд в следующем формате, полагая, что для этого будет применяться JSON-API:
{
error: 'SOME_ERROR_CODE',
description: 'Something bad happened. Please try again or contact support.'
}
Если на данном этапе происходящие кажется вам непонятным — не беспокойтесь — просто продолжайте читать, пробуйте работать с тем, о чём идёт речь, и постепенно вы во всём разберётесь. На самом деле, если говорить о компьютерном обучении, здесь применяется подход «сверху-вниз», когда сначала обсуждаются общие идеи, а потом осуществляется переход к частностям.
Вот как выглядит код обработчика маршрутов.
const express = require('express')
const router = express.Router()
const CustomError = require('../CustomError')
router.use(async (req, res) => {
try {
const route = require(`.${req.path}`)[req.method]
try {
const result = route(req) // Передаём запрос функции route
res.send(result) // Передаём клиенту то, что получено от функции route
} catch (err) {
/*
Сюда мы попадаем в том случае, если в функции route произойдёт ошибка
*/
if (err instanceof CustomError) {
/*
Если ошибка уже обработана - трансформируем её в
возвращаемый объект
*/
return res.status(err.status).send({
error: err.code,
description: err.message,
})
} else {
console.error(err) // Для отладочных целей
// Общая ошибка - вернём универсальный объект ошибки
return res.status(500).send({
error: 'GENERIC',
description: 'Something went wrong. Please try again or contact support.',
})
}
}
} catch (err) {
/*
Сюда мы попадём, если запрос окажется неудачным, то есть,
либо не будет найдено файла, соответствующего пути, переданному
в запросе, либо не будет экспортированной функции с заданным
методом запроса
*/
res.status(404).send({
error: 'NOT_FOUND',
description: 'The resource you tried to access does not exist.',
})
}
})
module.exports = router
Полагаем, комментарии в коде достаточно хорошо его поясняют. Надеемся, читать их удобнее, чем объяснения подобного кода, данные после него.
Теперь взглянем на файл маршрутов.
const CustomError = require('../CustomError')
const GET = req => {
// пример успешного выполнения запроса
return { name: 'Rio de Janeiro' }
}
const POST = req => {
// пример ошибки общего характера
throw new Error('Some unexpected error, may also be thrown by a library or the runtime.')
}
const DELETE = req => {
// пример ошибки, обрабатываемой особым образом
throw new CustomError('CITY_NOT_FOUND', 404, 'The city you are trying to delete could not be found.')
}
const PATCH = req => {
// пример перехвата ошибок и использования CustomError
try {
// тут случилось что-то нехорошее
throw new Error('Some internal error')
} catch (err) {
console.error(err) // принимаем решение о том, что нам тут делать
throw new CustomError(
'CITY_NOT_EDITABLE',
400,
'The city you are trying to edit is not editable.'
)
}
}
module.exports = {
GET,
POST,
DELETE,
PATCH,
}
В этих примерах с самими запросами ничего не делается. Тут просто рассматриваются разные сценарии возникновения ошибок. Итак, например, запрос GET /city
попадёт в функцию const GET = req =>...
, запрос POST /city
попадёт в функцию const POST = req =>...
и так далее. Эта схема работает и при использовании параметров запросов. Например — для запроса вида GET /city?startsWith=R
. В целом, здесь продемонстрировано, что при обработке ошибок, во фронтенд может попасть либо общая ошибка, содержащая лишь предложение попробовать снова или связаться с владельцем сервера, либо ошибка, сформированная с использованием конструктора CustomError
, которая содержит подробные сведения о проблеме.
Данные общей ошибки придут в клиентскую часть приложения в таком виде:
{
error: 'GENERIC',
description: 'Something went wrong. Please try again or contact support.'
}
Конструктор CustomError
используется так:
throw new CustomError('MY_CODE', 400, 'Error description')
Это даёт следующий JSON-код, передаваемый во фронтенд:
{
error: 'MY_CODE',
description: 'Error description'
}
Теперь, когда мы основательно потрудились над серверной частью приложения, в клиентскую часть больше не попадают бесполезные логи ошибок. Вместо этого клиент получает полезные сведения о том, что пошло не так.
Не забудьте о том, что здесь лежит репозиторий с рассматриваемым здесь кодом. Можете его загрузить, поэкспериментировать с ним, и, если надо, адаптировать под нужды вашего проекта.
3. Работа с ошибками на клиенте
Теперь пришла пора описать третью часть нашей системы обработки ошибок, касающуюся фронтенда. Тут нужно будет, во-первых, обрабатывать ошибки, возникающие в клиентской части приложения, а во-вторых, понадобится оповещать пользователя об ошибках, возникающих на сервере. Разберёмся сначала с показом сведений о серверных ошибках. Как уже было сказано, в этом примере будет использована библиотека React.
▍Сохранение сведений об ошибках в состоянии приложения
Как и любые другие данные, ошибки и сообщения об ошибках могут меняться, поэтому их имеет смысл помещать в состояние компонентов. При монтировании компонента данные об ошибке сбрасываются, поэтому, когда пользователь впервые видит страницу, там сообщений об ошибках не будет.
Следующее, с чем надо разобраться, заключается в том, что ошибки одного типа нужно показывать в одном стиле. По аналогии с сервером, здесь можно выделить 3 типа ошибок.
- Глобальные ошибки — в эту категорию попадают сообщения об ошибках общего характера, приходящие с сервера, или ошибки, которые, например, возникают в том случае, если пользователь не вошёл в систему и в других подобных ситуациях.
- Специфические ошибки, выдаваемые серверной частью приложения — сюда относятся ошибки, сведения о которых приходят с сервера. Например, подобная ошибка возникает, если пользователь попытался войти в систему и отправил на сервер имя и пароль, а сервер сообщил ему о том, что пароль неправильный. Подобные вещи в клиентской части приложения не проверяются, поэтому сообщения о таких ошибках должны приходить с сервера.
- Специфические ошибки, выдаваемые клиентской частью приложения. Пример такой ошибки — сообщение о некорректном адресе электронной почты, введённом в соответствующее поле.
Ошибки второго и третьего типов очень похожи, работать с ними можно, используя хранилище состояния компонентов одного уровня. Их главное различие заключается в том, что они исходят из разных источников. Ниже, анализируя код, мы посмотрим на работу с ними.
Здесь будет использоваться встроенная в React система управления состоянием приложения, но, при необходимости, вы можете воспользоваться и специализированными решениями для управления состоянием — такими, как MobX или Redux.
▍Глобальные ошибки
Обычно сообщения о таких ошибках сохраняются в компоненте наиболее высокого уровня, имеющем состояние. Они выводятся в статическом элементе пользовательского интерфейса. Это может быть красное поле в верхней части экрана, модальное окно или что угодно другое. Реализация зависит от конкретного проекта. Вот как выглядит сообщение о такой ошибке.
Сообщение о глобальной ошибке
Теперь взглянем на код, который хранится в файле Application.js
.
import React, { Component } from 'react'
import GlobalError from './GlobalError'
class Application extends Component {
constructor(props) {
super(props)
this.state = {
error: '',
}
this._resetError = this._resetError.bind(this)
this._setError = this._setError.bind(this)
}
render() {
return (
<div className="container">
<GlobalError error={this.state.error} resetError={this._resetError} />
<h1>Handling Errors</h1>
</div>
)
}
_resetError() {
this.setState({ error: '' })
}
_setError(newError) {
this.setState({ error: newError })
}
}
export default Application
Как видно, в состоянии, в Application.js
, имеется место для хранения данных ошибки. Кроме того, тут предусмотрены методы для сброса этих данных и для их изменения.
Ошибка и метод для сброса ошибки передаётся компоненту GlobalError
, который отвечает за вывод сообщения об ошибке на экран и за сброс ошибки после нажатия на значок x
в поле, где выводится сообщение. Вот код компонента GlobalError
(файл GlobalError.js
).
import React, { Component } from 'react'
class GlobalError extends Component {
render() {
if (!this.props.error) return null
return (
<div
style={{
position: 'fixed',
top: 0,
left: '50%',
transform: 'translateX(-50%)',
padding: 10,
backgroundColor: '#ffcccc',
boxShadow: '0 3px 25px -10px rgba(0,0,0,0.5)',
display: 'flex',
alignItems: 'center',
}}
>
{this.props.error}
<i
className="material-icons"
style={{ cursor: 'pointer' }}
onClick={this.props.resetError}
>
close
</font></i>
</div>
)
}
}
export default GlobalError
Обратите внимание на строку if (!this.props.error) return null
. Она указывает на то, что при отсутствии ошибки компонент ничего не выводит. Это предотвращает постоянный показ красного прямоугольника на странице. Конечно, вы, при желании, можете поменять внешний вид и поведение этого компонента. Например, вместо того, чтобы сбрасывать ошибку по нажатию на x
, можно задать тайм-аут в пару секунд, по истечении которого состояние ошибки сбрасывается автоматически.
Теперь, когда всё готово для работы с глобальными ошибками, для задания глобальной ошибки достаточно воспользоваться _setError
из Application.js
. Например, это можно сделать в том случае, если сервер, после обращения к нему, вернул сообщение об общей ошибке (error: 'GENERIC'
). Рассмотрим пример (файл GenericErrorReq.js
).
import React, { Component } from 'react'
import axios from 'axios'
class GenericErrorReq extends Component {
constructor(props) {
super(props)
this._callBackend = this._callBackend.bind(this)
}
render() {
return (
<div>
<button onClick={this._callBackend}>Click me to call the backend</button>
</div>
)
}
_callBackend() {
axios
.post('/api/city')
.then(result => {
// сделать что-нибудь с результатом в том случае, если запрос оказался успешным
})
.catch(err => {
if (err.response.data.error === 'GENERIC') {
this.props.setError(err.response.data.description)
}
})
}
}
export default GenericErrorReq
На самом деле, на этом наш разговор об обработке ошибок можно было бы и закончить. Даже если в проекте нужно оповещать пользователя о специфических ошибках, никто не мешает просто поменять глобальное состояние, хранящее ошибку и вывести соответствующее сообщение поверх страницы. Однако тут мы не остановимся и поговорим о специфических ошибках. Во-первых, это руководство по обработке ошибок иначе было бы неполным, а во-вторых, с точки зрения UX-специалистов, неправильно будет показывать сообщения обо всех ошибках так, будто все они — глобальные.
▍Обработка специфических ошибок, возникающих при выполнении запросов
Вот пример специфического сообщения об ошибке, выводимого в том случае, если пользователь пытается удалить из базы данных город, которого там нет.
Сообщение о специфической ошибке
Тут используется тот же принцип, который мы применяли при работе с глобальными ошибками. Только сведения о таких ошибках хранятся в локальном состоянии соответствующих компонентов. Работа с ними очень похожа на работу с глобальными ошибками. Вот код файла SpecificErrorReq.js
.
import React, { Component } from 'react'
import axios from 'axios'
import InlineError from './InlineError'
class SpecificErrorRequest extends Component {
constructor(props) {
super(props)
this.state = {
error: '',
}
this._callBackend = this._callBackend.bind(this)
}
render() {
return (
<div>
<button onClick={this._callBackend}>Delete your city</button>
<InlineError error={this.state.error} />
</div>
)
}
_callBackend() {
this.setState({
error: '',
})
axios
.delete('/api/city')
.then(result => {
// сделать что-нибудь с результатом в том случае, если запрос оказался успешным
})
.catch(err => {
if (err.response.data.error === 'GENERIC') {
this.props.setError(err.response.data.description)
} else {
this.setState({
error: err.response.data.description,
})
}
})
}
}
export default SpecificErrorRequest
Тут стоит отметить, что для сброса специфических ошибок недостаточно, например, просто нажать на некую кнопку x
. То, что пользователь прочёл сообщение об ошибке и закрыл его, не помогает такую ошибку исправить. Исправить её можно, правильно сформировав запрос к серверу, например — введя в ситуации, показанной на предыдущем рисунке, имя города, который есть в базе. В результате очищать сообщение об ошибке имеет смысл, например, после выполнения нового запроса. Сбросить ошибку можно и в том случае, если пользователь внёс изменения в то, что будет использоваться при формировании нового запроса, то есть — при изменении содержимого поля ввода.
▍Ошибки, возникающие в клиентской части приложения
Как уже было сказано, для хранения данных о таких ошибках можно использовать состояние тех же компонентов, которое используется для хранения данных по специфическим ошибкам, поступающим с сервера. Предположим, мы позволяем пользователю отправить на сервер запрос на удаление города из базы только в том случае, если в соответствующем поле ввода есть какой-то текст. Отсутствие или наличие текста в поле можно проверить средствами клиентской части приложения.
В поле ничего нет, мы сообщаем об этом пользователю
Вот код файла SpecificErrorFrontend.js
, реализующий вышеописанный функционал.
import React, { Component } from 'react'
import axios from 'axios'
import InlineError from './InlineError'
class SpecificErrorRequest extends Component {
constructor(props) {
super(props)
this.state = {
error: '',
city: '',
}
this._callBackend = this._callBackend.bind(this)
this._changeCity = this._changeCity.bind(this)
}
render() {
return (
<div>
<input
type="text"
value={this.state.city}
style={{ marginRight: 15 }}
onChange={this._changeCity}
/>
<button onClick={this._callBackend}>Delete your city</button>
<InlineError error={this.state.error} />
</div>
)
}
_changeCity(e) {
this.setState({
error: '',
city: e.target.value,
})
}
_validate() {
if (!this.state.city.length) throw new Error('Please provide a city name.')
}
_callBackend() {
this.setState({
error: '',
})
try {
this._validate()
} catch (err) {
return this.setState({ error: err.message })
}
axios
.delete('/api/city')
.then(result => {
// сделать что-нибудь с результатом в том случае, если запрос оказался успешным
})
.catch(err => {
if (err.response.data.error === 'GENERIC') {
this.props.setError(err.response.data.description)
} else {
this.setState({
error: err.response.data.description,
})
}
})
}
}
export default SpecificErrorRequest
▍Интернационализация сообщений об ошибках с использованием кодов ошибок
Возможно, сейчас вы задаётесь вопросом о том, зачем нам нужны коды ошибок (наподобие GENERIC
), если мы показываем пользователю только сообщения об ошибках, полученных с сервера. Дело в том, что, по мере роста и развития приложения, оно, вполне возможно, выйдет на мировой рынок, а это означает, что настанет время, когда создателям приложения нужно будет задуматься о поддержке им нескольких языков. Коды ошибок позволяют отличать их друг от друга и выводить сообщения о них на языке пользователя сайта.
Итоги
Надеемся, теперь у вас сформировалось понимание того, как можно работать с ошибками в веб-приложениях. Нечто вроде console.error(err)
следует использовать только в отладочных целях, в продакшн подобные вещи, забытые программистом, проникать не должны. Упрощает решение задачи логирования использование какой-нибудь подходящей библиотеки наподобие loglevel.
Уважаемые читатели! Как вы обрабатываете ошибки в своих проектах?
Существует ряд причин, по которым код JavaScript может вызывать ошибки, например:
- Проблема с сетевым подключением;
- Пользователь мог ввести неверное значение в поля формы;
- Ссылка на объекты или функции, которые не существуют;
- Неправильные данные отправляются или принимаются с веб-сервера;
- Служба, к которой приложение должно получить доступ, может быть временно недоступна.
Эти типы ошибок известны как ошибки времени выполнения (runtime errors), поскольку они возникают во время выполнения скрипта. Профессиональное приложение должно иметь возможность корректно обрабатывать такие ошибки во время выполнения. Обычно это означает понятное информирование пользователя о возникшей проблеме.
Оператор try…catch
JavaScript предоставляет оператор try-catch
, чтобы перехватывать ошибки времени выполнения и корректно их обработать.
Любой код, который может вызвать ошибку, должен быть помещен в блок оператора try
, а код для обработки ошибки помещен в блок catch
, как показано здесь:
try {
// Код, который может вызвать ошибку
} catch(error) {
// Действие, которое нужно выполнить при возникновении ошибки
}
Если ошибка возникает в любой точке блока try
, выполнение кода немедленно переносится из блока try
в блок catch
. Если в блоке try
ошибки не возникает, блок catch
будет проигнорирован, и программа продолжит выполнение после оператора try-catch
.
Следующий пример демонстрирует, как работает оператор try-catch
:
try {
var greet = "Hi, there!";
document.write(greet);
// Попытка получить доступ к несуществующей переменной
document.write(welcome);
// Если произошла ошибка, следующая строка не будет выполнена
alert("All statements are executed successfully.");
} catch(error) {
// Обработка ошибки
alert("Caught error: " + error.message);
}
// Продолжаем исполнение кода
document.write("<p>Hello World!</p>");
Приведенный выше скрипт генерирует ошибку, которая отображается в диалоговом окне с предупреждением, а не выводится в консоль браузера. Кроме того, программа не остановилась внезапно, даже если произошла ошибка.
Также обратите внимание, что за ключевым словом catch
указывается идентификатор в скобках. Этот идентификатор действует как параметр функции. При возникновении ошибки интерпретатор JavaScript генерирует объект, содержащий сведения о нем. Этот объект ошибки затем передается в качестве аргумента для обработки.
Оператор try-catch
является механизмом обработки исключений. Исключением является сигнал, который указывает, что во время выполнения программы возникли какие-то исключительные условия или ошибки. Термины «исключение» и «ошибка» часто используются взаимозаменяемо.
Оператор try…catch…finally
Оператор try-catch
также может содержать предложение finally
. Код внутри блока finally
всегда будет выполняться независимо от того, произошла ошибка в блоке try
или нет.
В следующем примере всегда отображается общее время, затраченное на выполнение кода.
// Присвоение значения, возвращаемого диалоговым окном
var num = prompt("Enter a positive integer between 0 to 100");
// Запоминание времени начала исполнения
var start = Date.now();
try {
if(num > 0 && num <= 100) {
alert(Math.pow(num, num)); // the base to the exponent power
} else {
throw new Error("An invalid value is entered!");
}
} catch(e) {
alert(e.message);
} finally {
// Отображение времени, необходимого для выполнения кода
alert("Execution took: " + (Date.now() - start) + "ms");
}
Вызов ошибок с помощью оператора throw
До сих пор мы видели ошибки, которые автоматически генерируются парсером JavaScript. Тем не менее, также можно вызвать ошибку вручную с помощью оператора throw
.
Общий синтаксис оператора throw
: throw expression;
Выражение expression
может быть объектом или значением любого типа данных. Однако лучше использовать объекты, желательно со свойствами name
и message
. Встроенный в JavaScript конструктор Error()
предоставляет удобный способ создания объекта ошибки. Давайте посмотрим на некоторые примеры:
throw 123;
throw "Missing values!";
throw true;
throw { name: "InvalidParameter", message: "Parameter is not a number!" };
throw new Error("Something went wrong!");
Если вы используете встроенные в JavaScript функции конструктора ошибок (например, Error()
, TypeError()
и т. д.) для создания объектов ошибок, тогда свойство name
совпадает с именем конструктора, а message
равно аргументу функции конструктора.
Теперь мы собираемся создать функцию squareRoot()
, чтобы найти квадратный корень числа. Это можно сделать просто с помощью встроенной в JavaScript функции Math.sqrt()
, но проблема здесь в том, что она возвращает NaN
для отрицательных чисел, не давая никаких подсказок о том, что пошло не так.
Мы собираемся исправить эту проблему, показывая пользователю ошибку, если указано отрицательное число.
function squareRoot(number) {
// Выдает ошибку, если число отрицательное
if(number < 0) {
throw new Error("Sorry, can't calculate square root of a negative number.");
} else {
return Math.sqrt(number);
}
}
try {
squareRoot(16);
squareRoot(625);
squareRoot(-9);
squareRoot(100);
// Если выдается ошибка, следующая строка не будет выполнена
alert("All calculations are performed successfully.");
} catch(e) {
// Обработка ошибки
alert(e.message);
}
Теоретически можно вычислить квадратный корень из отрицательного числа, используя мнимое число i
, где i2 = -1. Следовательно, квадратный корень из -4
равен 2i
, квадратный корень из -9
равен 3i
и так далее. Но мнимые числа не поддерживаются в JavaScript.
Типы ошибок
Объект Error
является базовым типом всех ошибок и имеет два основных свойства: name
, указывающее тип ошибки и свойство message
, которое содержит сообщение, описывающее ошибку более подробно. Любая выданная ошибка будет экземпляром объекта Error
.
Существует несколько различных типов ошибок, которые могут возникнуть во время выполнения программы JavaScript, например RangeError
, ReferenceError
, SyntaxError
, TypeError
, и URIError
.
В следующем разделе описывается каждый из этих типов ошибок более подробно:
RangeError
RangeError
генерируется, когда вы используете число, выходящее за пределы допустимых значений. Например, создание массива с отрицательной длиной вызовет RangeError
.
var num = 12.735;
num.toFixed(200); // выдает ошибку диапазона (допустимый диапазон от 0 до 100)
var array = new Array(-1); // выдает ошибку диапазона
ReferenceError
Ошибка ReferenceError
обычно выдается, когда вы пытаетесь сослаться на переменную или объект, которые не существуют, или получить к ним доступ. В следующем примере показано, как происходит ошибка ReferenceError
.
var firstName = "Harry";
console.log(firstname); // выдает ошибку ссылки (имена переменных чувствительны к регистру)
undefinedObj.getValues(); // выдает ошибку ссылки
nonexistentArray.length; // выдает ошибку ссылки
SyntaxError
SyntaxError
генерируется, если в вашем коде JavaScript есть какие-либо синтаксические проблемы. Например, если закрывающая скобка отсутствует, циклы не структурированы должным образом и т. д.
var array = ["a", "b", "c"];
document.write(array.slice(2); // выдает синтаксическую ошибку (отсутствует скобка)
alert("Hello World!'); // выдает синтаксическую ошибку (несоответствие кавычек)
TypeError
Ошибка TypeError
возникает, когда значение не относится к ожидаемому типу. Например, вызов метода строки для числа, вызов метода массива для строки и т. д.
var num = 123;
num.toLowerCase(); /* выдает ошибку (поскольку toLowerCase() является строковым методом, число не может быть преобразовано в нижний регистр) */
var greet = "Hello World!"
greet.join() // выдает ошибку (так как join() является методом массива)
URIError
URIError
генерируется, когда вы указали недопустимый URI (расшифровывается как Uniform Resource Identifier) для функций, связанных с URI, таких как encodeURI()
или decodeURI()
, как показано здесь:
var a = "%E6%A2%B";
decodeURI(a); // выдает ошибку URI
var b = "uD800";
encodeURI(b); // выдает ошибку URI
Существует еще один тип ошибки EvalError
, который генерируется при возникновении ошибки во время выполнения кода с помощью функции eval()
. Хотя эта ошибка больше не генерируется JavaScript, этот объект все еще остается для обратной совместимости.
Конкретный тип ошибки также может быть выдан вручную с использованием соответствующего конструктора и оператора throw
. Например, чтобы сгенерировать ошибку TypeError
, вы можете использовать конструктор TypeError()
, например:
var num = prompt("Please enter a number");
try {
if(num != "" && num !== null && isFinite(+num)) {
alert(Math.exp(num));
} else {
throw new TypeError("You have not entered a number.");
}
} catch(e) {
alert(e.name);
alert(e.message);
alert(e.stack); // нестандартное свойство
}
Объект Error
также поддерживает некоторые нестандартные свойства. Одним из наиболее широко используемых таких свойств является: stack trace, который возвращает трассировку стека для этой ошибки. Вы можете использовать его в целях отладки, но не используйте его на рабочих сайтах.
Пользовательские ошибки, расширение Error
Когда что-то разрабатываем, то нам часто необходимы собственные классы ошибок для разных вещей, которые могут пойти не так в наших задачах. Для ошибок при работе с сетью может понадобиться HttpError
, для операций с базой данных DbError
, для поиска — NotFoundError
и т.д.
Наши ошибки должны поддерживать базовые свойства, такие как message
, name
и, желательно, stack
. Но также они могут иметь свои собственные свойства. Например, объекты HttpError
могут иметь свойство statusCode
со значениями 404
, 403
или 500
.
JavaScript позволяет вызывать throw
с любыми аргументами, то есть технически наши классы ошибок не нуждаются в наследовании от Error
. Но если использовать наследование, то появляется возможность идентификации объектов ошибок посредством obj instanceof Error
. Так что лучше применять наследование.
По мере роста приложения, наши собственные ошибки образуют иерархию, например, HttpTimeoutError
может наследовать от HttpError
и так далее.
Расширение Error
В качестве примера рассмотрим функцию readUser(json)
, которая должна читать данные пользователя в формате JSON.
Пример того, как может выглядеть корректный json
:
let json = `{ "name": "John", "age": 30 }`;
Внутри будем использовать JSON.parse
. При получении некорректного json
он будет генерировать ошибку SyntaxError
. Но даже если json
синтаксически верен, то это не значит, что это будет корректный пользователь, верно? Могут быть пропущены необходимые данные. Например, могут отсутствовать свойства name
и age
, которые являются необходимыми для наших пользователей.
Наша функция readUser(json)
будет не только читать JSON-данные, но и проверять их («валидировать»). Если необходимые поля отсутствуют или данные в неверном формате, то это будет ошибкой. Но не синтаксической ошибкой SyntaxError
, потому что данные синтаксически корректны. Это будет другая ошибка.
Назовём её ошибкой валидации ValidationError
и создадим для неё класс. Ошибка этого вида должна содержать информацию о поле, которое является источником ошибки.
Наш класс ValidationError
должен наследовать от встроенного класса Error
.
Класс Error
встроенный, вот его примерный код, просто чтобы мы понимали, что расширяем:
// "Псевдокод" встроенного класса Error, определённого самим JavaScript class Error { constructor(message) { this.message = message; this.name = "Error"; // (разные имена для разных встроенных классов ошибок) this.stack = <стек вызовов>; // нестандартное свойство, но обычно поддерживается } }
Теперь давайте унаследуем от него ValidationError
и попробуем новый класс в действии:
*!* class ValidationError extends Error { */!* constructor(message) { super(message); // (1) this.name = "ValidationError"; // (2) } } function test() { throw new ValidationError("Упс!"); } try { test(); } catch(err) { alert(err.message); // Упс! alert(err.name); // ValidationError alert(err.stack); // список вложенных вызовов с номерами строк для каждого }
Обратите внимание: в строке (1)
вызываем родительский конструктор. JavaScript требует от нас вызова super
в дочернем конструкторе, так что это обязательно. Родительский конструктор устанавливает свойство message
.
Родительский конструктор также устанавливает свойство name
для "Error"
, поэтому в строке (2)
мы сбрасываем его на правильное значение.
Попробуем использовать его в readUser(json)
:
class ValidationError extends Error { constructor(message) { super(message); this.name = "ValidationError"; } } // Использование function readUser(json) { let user = JSON.parse(json); if (!user.age) { throw new ValidationError("Нет поля: age"); } if (!user.name) { throw new ValidationError("Нет поля: name"); } return user; } // Рабочий пример с try..catch try { let user = readUser('{ "age": 25 }'); } catch (err) { if (err instanceof ValidationError) { *!* alert("Некорректные данные: " + err.message); // Некорректные данные: Нет поля: name */!* } else if (err instanceof SyntaxError) { // (*) alert("JSON Ошибка Синтаксиса: " + err.message); } else { throw err; // неизвестная ошибка, пробросить исключение (**) } }
Блок try..catch
в коде выше обрабатывает и нашу ValidationError
, и встроенную SyntaxError
из JSON.parse
.
Обратите внимание, как мы используем instanceof
для проверки конкретного типа ошибки в строке (*)
.
Мы можем также проверить тип, используя err.name
:
// ... // вместо (err instanceof SyntaxError) } else if (err.name == "SyntaxError") { // (*) // ...
Версия с instanceof
гораздо лучше, потому что в будущем мы собираемся расширить ValidationError
, сделав его подтипы, такие как PropertyRequiredError
. И проверка instanceof
продолжит работать для новых наследованных классов. Так что это на будущее.
Также важно, что если catch
встречает неизвестную ошибку, то он пробрасывает её в строке (**)
. Блокcatch
знает, только как обрабатывать ошибки валидации и синтаксические ошибки, а другие виды ошибок (из-за опечаток в коде и другие непонятные) он должен выпустить наружу.
Дальнейшее наследование
Класс ValidationError
является слишком общим. Много что может пойти не так. Свойство может отсутствовать или иметь неверный формат (например, строка как значение возраста age
). Поэтому для отсутствующих свойств сделаем более конкретный класс PropertyRequiredError
. Он будет нести дополнительную информацию о свойстве, которое отсутствует.
class ValidationError extends Error { constructor(message) { super(message); this.name = "ValidationError"; } } *!* class PropertyRequiredError extends ValidationError { constructor(property) { super("Нет свойства: " + property); this.name = "PropertyRequiredError"; this.property = property; } } */!* // Применение function readUser(json) { let user = JSON.parse(json); if (!user.age) { throw new PropertyRequiredError("age"); } if (!user.name) { throw new PropertyRequiredError("name"); } return user; } // Рабочий пример с try..catch try { let user = readUser('{ "age": 25 }'); } catch (err) { if (err instanceof ValidationError) { *!* alert("Неверные данные: " + err.message); // Неверные данные: Нет свойства: name alert(err.name); // PropertyRequiredError alert(err.property); // name */!* } else if (err instanceof SyntaxError) { alert("Ошибка синтаксиса JSON: " + err.message); } else { throw err; // неизвестная ошибка, повторно выбросит исключение } }
Новый класс PropertyRequiredError
очень просто использовать: необходимо указать только имя свойства new PropertyRequiredError(property)
. Сообщение для пользователя message
генерируется конструктором.
Обратите внимание, что свойство this.name
в конструкторе PropertyRequiredError
снова присвоено вручную. Правда, немного утомительно — присваивать this.name = <class name>
в каждом классе пользовательской ошибки. Можно этого избежать, если сделать наш собственный «базовый» класс ошибки, который будет ставить this.name = this.constructor.name
. И затем наследовать все ошибки уже от него.
Давайте назовём его MyError
.
Вот упрощённый код с MyError
и другими пользовательскими классами ошибок:
class MyError extends Error { constructor(message) { super(message); *!* this.name = this.constructor.name; */!* } } class ValidationError extends MyError { } class PropertyRequiredError extends ValidationError { constructor(property) { super("Нет свойства: " + property); this.property = property; } } // name корректное alert( new PropertyRequiredError("field").name ); // PropertyRequiredError
Теперь пользовательские ошибки стали намного короче, особенно ValidationError
,
так как мы избавились от строки "this.name = ..."
в конструкторе.
Обёртывание исключений
Назначение функции readUser
в приведённом выше коде — это «чтение данных пользователя». В процессе могут возникнуть различные виды ошибок. Сейчас у нас есть SyntaxError
и ValidationError
, но в будущем функция readUser
может расшириться и, возможно, генерировать другие виды ошибок.
Код, который вызывает readUser
, должен обрабатывать эти ошибки.
Сейчас в нём используются проверки if
в блоке catch
, которые проверяют класс и обрабатывают известные ошибки и пробрасывают дальше неизвестные. Но если функция readUser
генерирует несколько видов ошибок, то мы должны спросить себя: действительно ли мы хотим проверять все типы ошибок поодиночке во всех местах в коде, где вызывается readUser
?
Часто ответ «Нет»: внешний код хочет быть на один уровень выше всего этого. Он хочет иметь какую-то обобщённую ошибку чтения данных. Почему именно это произошло — часто не имеет значения (об этом говорится в сообщении об ошибке). Или даже лучше, если есть способ получить подробности об ошибке, но только если нам это нужно.
Итак, давайте создадим новый класс ReadError
для представления таких ошибок. Если ошибка возникает внутри readUser
, мы её перехватим и сгенерируем ReadError
. Мы также сохраним ссылку на исходную ошибку в свойстве cause
. Тогда внешний код должен будет только проверить наличие ReadError
.
Этот код определяет ошибку ReadError
и демонстрирует её использование в readUser
и try..catch
:
class ReadError extends Error { constructor(message, cause) { super(message); this.cause = cause; this.name = 'ReadError'; } } class ValidationError extends Error { /*...*/ } class PropertyRequiredError extends ValidationError { /* ... */ } function validateUser(user) { if (!user.age) { throw new PropertyRequiredError("age"); } if (!user.name) { throw new PropertyRequiredError("name"); } } function readUser(json) { let user; try { user = JSON.parse(json); } catch (err) { *!* if (err instanceof SyntaxError) { throw new ReadError("Синтаксическая ошибка", err); } else { throw err; } */!* } try { validateUser(user); } catch (err) { *!* if (err instanceof ValidationError) { throw new ReadError("Ошибка валидации", err); } else { throw err; } */!* } } try { readUser('{bad json}'); } catch (e) { if (e instanceof ReadError) { *!* alert(e); // Исходная ошибка: SyntaxError:Unexpected token b in JSON at position 1 alert("Исходная ошибка: " + e.cause); */!* } else { throw e; } }
В приведённом выше коде readUser
работает так, как описано — функция распознаёт синтаксические ошибки и ошибки валидации и выдаёт вместо них ошибки ReadError
(неизвестные ошибки, как обычно, пробрасываются).
Внешний код проверяет только instanceof ReadError
. Не нужно перечислять все возможные типы ошибок
Этот подход называется «обёртывание исключений», потому что мы берём «исключения низкого уровня» и «оборачиваем» их в ReadError
, который является более абстрактным и более удобным для использования в вызывающем коде. Такой подход широко используется в объектно-ориентированном программировании.
Итого
- Мы можем наследовать свои классы ошибок от
Error
и других встроенных классов ошибок, но нужно позаботиться о свойствеname
и не забыть вызватьsuper
. - Мы можем использовать
instanceof
для проверки типа ошибок. Это также работает с наследованием. Но иногда у нас объект ошибки, возникшей в сторонней библиотеке, и нет простого способа получить класс. Тогда для проверки типа ошибки можно использовать свойствоname
. - Обёртывание исключений является распространённой техникой: функция ловит низкоуровневые исключения и создаёт одно «высокоуровневое» исключение вместо разных низкоуровневых. Иногда низкоуровневые исключения становятся свойствами этого объекта, как
err.cause
в примерах выше, но это не обязательно.