Как совершить ошибку в экспрессе

Время на прочтение
7 мин

Количество просмотров 22K

Когда я только начинал работать с Express и пытался разобраться с тем, как обрабатывать ошибки, мне пришлось нелегко. Возникало такое ощущение, будто никто не писал о том, что мне было нужно. В итоге мне пришлось самому искать ответы на мои вопросы. Сегодня я хочу рассказать всё, что знаю об обработке ошибок в Express-приложениях. Начнём с синхронных ошибок.

Обработка синхронных ошибок

Если вам нужно обработать синхронную ошибку, то вы можете, для начала, с помощью инструкции throw, выдать такую ошибку в обработчике запроса Express. Обратите внимание на то, что обработчики запросов ещё называют «контроллерами», но я предпочитаю использовать термин «обработчик запросов» так как он кажется мне понятнее.

Вот как это выглядит:

app.post('/testing', (req, res) => {
  throw new Error('Something broke! ')
})

Такие ошибки можно перехватить с помощью обработчика ошибок Express. Если вы не написали собственный обработчик ошибок (подробнее об этом мы поговорим ниже), то Express обработает ошибку с помощью обработчика, используемого по умолчанию.

Вот что делает стандартный обработчик ошибок Express:

1. Устанавливает код состояния HTTP-ответа в значение 500.
2. Отправляет сущности, выполнившей запрос, текстовый ответ.
3. Логирует текстовый ответ в консоль.

Сообщение об ошибке, выведенное в консоль

Обработка асинхронных ошибок

Для обработки асинхронных ошибок нужно отправить ошибку обработчику ошибок Express через аргумент next:

app.post('/testing', async (req, res, next) => {
  return next(new Error('Something broke again! '))
})

Вот что попадёт в консоль при логировании этой ошибки.

Сообщение об ошибке, выведенное в консоль

Если вы пользуетесь в Express-приложении конструкцией async/await, то вам понадобится использовать функцию-обёртку, наподобие express-async-handler. Это позволяет писать асинхронный код без блоков try/catch. Подробнее об async/await в Express можно почитать здесь.

const asyncHandler = require('express-async-handler')

app.post('/testing', asyncHandler(async (req, res, next) => {
  // Сделать что-нибудь
}))

После того, как обработчик запроса обёрнут в express-async-handler, то можно, так же, как было описано выше, выбросить ошибку с использованием инструкции throw. Эта ошибка попадёт к обработчику ошибок Express.

app.post('/testing', asyncHandler(async (req, res, next) => {
  throw new Error('Something broke yet again! ')
}))

Сообщение об ошибке, выведенное в консоль

Написание собственного обработчика ошибок

Обработчики ошибок Express принимают 4 аргумента:

1. error
2. req
3. res
4. next

Размещать их нужно после промежуточных обработчиков и маршрутов.

app.use(/*...*/)
app.get(/*...*/)
app.post(/*...*/)
app.put(/*...*/)
app.delete(/*...*/)

// Собственный обработчик ошибок нужно поместить после всех остальных промежуточных обработчиков
app.use((error, req, res, next) => { /* ... */ })

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

1. Сформировать и отправить подходящий код состояния ответа.
2. Сформировать и отправить подходящий ответ.

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

1. Ошибка 400 Bad Request. Используется в двух ситуациях. Во-первых — тогда, когда пользователь не включил в запрос необходимое поле (например — в отправленной платёжной форме не заполнено поле со сведениями о кредитной карте). Во-вторых — тогда, когда в запросе содержатся некорректные данные (например — ввод в поле пароля и в поле подтверждения пароля разных паролей).
2. Ошибка 401 Unauthorized. Этот код состояния ответа применяется в том случае, если пользователь ввёл неправильные учётные данные (вроде имени пользователя, адреса электронной почты или пароля).
3. Ошибка 403 Forbidden. Используется в тех случаях, когда пользователю не разрешён доступ к конечной точке.
4. Ошибка 404 Not Found. Применяется в тех случаях, когда конечную точку невозможно обнаружить.
5. Ошибка 500 Internal Server Error. Применяется тогда, когда запрос, отправленный фронтендом, сформирован правильно, но на бэкенде при этом возникла какая-то ошибка.

После того, как определён подходящий код состояния ответа, его нужно установить с помощью res.status:

app.use((error, req, res, next) => {
  // Ошибка, выдаваемая в ответ на неправильно сформированный запрос
  res.status(400)
  res.json(/* ... */)
})

Код состояния ответа должен соответствовать сообщению об ошибке. Для этого нужно отправлять код состояния вместе с ошибкой.

Легче всего это сделать с помощью пакета http-errors. Он позволяет отправлять в ошибке три фрагмента информации:

1. Код состояния ответа.
2. Сообщение, сопутствующее ошибке.
3. Любые данные, которые нужно отправить (это необязательно).

Вот как установить пакет http-errors:

npm install http-errors --save

Вот как этим пакетом пользоваться:

const createError = require('http-errors')

// Создание ошибки
throw createError(status, message, properties)

Рассмотрим пример, который позволит как следует в этом всём разобраться.

Представим, что мы пытаемся обнаружить пользователя по адресу его электронной почты. Но этого пользователя найти не удаётся. В результате мы решаем отправить в ответ на соответствующий запрос ошибку User not found, сообщающую вызывающей стороне о том, что пользователь не найден.

Вот что нам нужно будет сделать при создании ошибки:

1. Установить код состояния ответа как 400 Bad Request (ведь пользователь ввёл неправильные данные). Это будет наш первый параметр.
2. Отправить вызывающей стороне сообщение наподобие User not found. Это будет второй параметр.

app.put('/testing', asyncHandler(async (req, res) => {
  const { email } = req.body
  const user = await User.findOne({ email })

  // Если пользователь не найден - выбросим ошибку
  if (!user) throw createError(400, `User '${email}' not found`)
}))

Получить код состояния можно с помощью конструкции error.status, а сообщение ошибки — с помощью error.message:

// Логирование ошибки
app.use((error, req, res, next) => {
  console.log('Error status: ', error.status)
  console.log('Message: ', error.message)
})

Результат логирования ошибки в консоли

Затем состояние ответа устанавливают с помощью res.status, а сообщение записывают в res.json:

app.use((error, req, res, next) => {
  // Установка кода состояния ответа
  res.status(error.status)

  // Отправка ответа
  res.json({ message: error.message })
})

Лично я предпочитаю отправлять в подобных ответах код состояния, сообщение и результат трассировки стека. Это облегчает отладку.

app.use((error, req, res, next) => {
  // Установка кода состояния ответа
  res.status(error.status)

  // Отправка ответа
  res.json({
    status: error.status,
    message: error.message,
    stack: error.stack
  })
})

▍Код состояния ответа, используемый по умолчанию

Если источником ошибки не является createError, то у неё не будет свойства status. Вот пример, в котором сделана попытка прочесть несуществующий файл с помощью fs.readFile:

const fs = require('fs')
const util = require('util')

// Преобразуем readFile из функции, использующей коллбэки, в async/await-функцию.
// Подробности об этом смотрите здесь: https://zellwk.com/blog/callbacks-to-promises
const readFilePromise = util.promisify(fs.readFile)

app.get('/testing', asyncHandler(async (req, res, next) => {
  const data = await readFilePromise('some-file')
})

У такого объекта ошибки не будет свойства status:

app.use((error, req, res, next) => {
  console.log('Error status: ', error.status)
  console.log('Message: ', error.message)
})

Результат логирования ошибки в консоли

В подобных случаях можно задать код ошибки, используемый по умолчанию. А именно, речь идёт об ошибке 500 Internal Server Error:

app.use((error, req, res, next) => {
  res.status(error.status || 500)
  res.json({
    status: error.status,
    message: error.message,
    stack: error.stack
  })
})

▍Изменение кода состояния ошибки

Предположим, мы собираемся прочитать некий файл, воспользовавшись данными, предоставленными пользователем. Если такого файла не существует, это значит, что нам нужно выдать ошибку 400 Bad Request. Ведь в том, что файл найти не удаётся, нет вины сервера.

В подобном случае нужно воспользоваться конструкцией try/catch для перехвата исходной ошибки. Затем нужно воссоздать объект ошибки с помощью createError:

app.get('/testing', asyncHandler(async (req, res, next) => {
  try {
    const { file } = req.body
    const contents = await readFilePromise(path.join(__dirname, file))
  } catch (error) {
    throw createError(400, `File ${file} does not exist`)
  }
})

▍Обработка ошибок 404

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

Для обработки ошибок 404 Not Found нужно добавить, между маршрутами и обработчиком ошибок, дополнительный обработчик. Вот как выглядит создание объекта ошибки 404:

// Промежуточные обработчики...
// Маршруты...

app.use((req, res, next) => {
  next(createError(404))
})

// Обработчик ошибок...

Сведения об ошибке

▍Замечания об ошибке ERR_HTTP_HEADERS_SENT

Не впадайте в панику если видите сообщение об ошибке ERR_HTTP_HEADERS_SENT: Cannot set headers after they are sent to the client. Она возникает из-за того, что в одном и том же обработчике многократно вызывается метод, устанавливающий заголовки ответа. Вот методы, вызов которых приводит к автоматической установке заголовков ответа:

1. res.send
2. res.json
3. res.render
4. res.sendFile
5. res.sendStatus
6. res.end
7. res.redirect

Так, например, если вы вызовете методы res.render и res.json в одном и том же обработчике ответа, то вы получите ошибку ERR_HTTP_HEADERS_SENT:

app.get('/testing', (req, res) => {
  res.render('new-page')
  res.json({ message: '¯_(ツ)_/¯' })
})

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

▍Обработка ошибок и потоковая передача данных

Если что-то идёт не так при потоковой передаче ответа фронтенду, то можно столкнуться с той же самой ошибкой ERR_HTTP_HEADERS_SENT.

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

app.use((error, req, res, next) => {
  // Сделать это нужно только в том случае, если ответ передаётся в потоковом режиме
  if (res.headersSent) {
    return next(error)
  }

  // Остальной код обработки ошибок
})

Итоги

Сегодня я рассказал вам всё, что знаю об обработке ошибок в Express. Надеюсь, это поможет вам писать более надёжные Express-приложения.

Уважаемые читатели! Как вы обрабатываете ошибки в своих Node.js-проектах?

Обработка ошибок

Функции промежуточного обработчика для обработки ошибок определяются так же, как и другие функции промежуточной обработки, но с указанием для функции обработки ошибок не трех, а четырех аргументов: (err, req, res, next). Например:

app.use(function(err, req, res, next) {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

Промежуточный обработчик для обработки ошибок должен быть определен последним, после указания всех app.use() и вызовов маршрутов; например:

var bodyParser = require('body-parser');
var methodOverride = require('method-override');

app.use(bodyParser());
app.use(methodOverride());
app.use(function(err, req, res, next) {
  // logic
});

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

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

var bodyParser = require('body-parser');
var methodOverride = require('method-override');

app.use(bodyParser());
app.use(methodOverride());
app.use(logErrors);
app.use(clientErrorHandler);
app.use(errorHandler);

В данном примере базовый код logErrors может записывать информацию о запросах и ошибках в stderr, например:

function logErrors(err, req, res, next) {
  console.error(err.stack);
  next(err);
}

Кроме того, в данном примере clientErrorHandler определен, как указано ниже; в таком случае ошибка явным образом передается далее следующему обработчику:

function clientErrorHandler(err, req, res, next) {
  if (req.xhr) {
    res.status(500).send({ error: 'Something failed!' });
  } else {
    next(err);
  }
}

“Обобщающая” функция errorHandler может быть реализована так:

function errorHandler(err, req, res, next) {
  res.status(500);
  res.render('error', { error: err });
}

При передаче какого-либо объекта в функцию next() (кроме строки 'route'), Express интерпретирует текущий запрос как ошибку и пропустит все остальные функции маршрутизации и промежуточной обработки, не являющиеся функциями обработки ошибок. Для того чтобы обработать данную ошибку определенным образом, необходимо создать маршрут обработки ошибок, как описано в следующем разделе.

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

app.get('/a_route_behind_paywall',
  function checkIfPaidSubscriber(req, res, next) {
    if(!req.user.hasPaid) {

      // continue handling this request
      next('route');
    }
  }, function getPaidContent(req, res, next) {
    PaidContent.find(function(err, doc) {
      if(err) return next(err);
      res.json(doc);
    });
  });

В данном примере обработчик getPaidContent будет пропущен, но выполнение всех остальных обработчиков в app для /a_route_behind_paywall будет продолжено.

Вызовы next() и next(err) указывают на завершение выполнения текущего обработчика и на его состояние. next(err) пропускает все остальные обработчики в цепочке, кроме заданных для обработки ошибок, как описано выше.

Стандартный обработчик ошибок

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

В случае передачи ошибки в next() без обработки с помощью обработчика ошибок, такая ошибка будет обработана встроенным обработчиком ошибок. Ошибка будет записана на клиенте с помощью трассировки стека. Трассировка стека не включена в рабочую среду.

Для запуска приложения в рабочем режиме необходимо задать для переменной среды NODE_ENV значение production.

При вызове next() с ошибкой после начала записи ответа
(например, если ошибка обнаружена во время включения ответа в поток, направляемый клиенту), стандартный обработчик ошибок Express закрывает соединение и отклоняет запрос.

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

function errorHandler(err, req, res, next) {
  if (res.headersSent) {
    return next(err);
  }
  res.status(500);
  res.render('error', { error: err });
}

Что такое возврат в ставках на спорт и когда он происходит

Возврат в ставках на спорт — расчёт с коэффициентом 1.00, то есть выплата игроку суммы его пари в полном объёме. Без выигрыша или проигрыша. Клиент поставил 100 рублей — оператор вернёт 100, поставил 30 тыс. рублей — столько же и вернётся.

Существуют разные ситуации, при которых букмекер прибегает к данному виду расчёта:

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

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

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

Виды возвратов при европейских и азиатских форах и тоталах

Возврат в ставках на спорт предусмотрен в основном в форах и тоталах. Они бывают европейского и азиатского типа.

В европейском формате пари по форам и тоталам даются полуторными дробями или целыми числами. При ставке на последний вариант и возникает возможность расчёта с коэффициентом 1.00.

Например, заключаем на футбольный матч пари тотал больше 3 голов. Команды завершают игру со счётом 2:1 (или 3:0), то есть забивают ровно три гола, что полностью совпадает с нашим предположением, но не превышает его. Поэтому букмекер только возвращает поставленную нами сумму, а не выплачивает выигрыш. При этом победитель встречи значения не имеет.

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

Например, ставим на тот же матч ТБ 2.75 мяча. При забитых трёх голах во встрече половина суммы возвращается, а другая рассчитывается выигрышем. Одна рассматривается как ТБ 3, а другая — ТБ 2.5.

Championat.com

Что такое экспресс-пари и как на него влияет возврат при ставках

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

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

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

Пример расчёта экспресса с возвратом по одному событию

Разберём, как отображается на итоговом коэффициенте экспресс-ставки возврат по одному или нескольким событиям на конкретном примере.

Составляем экспресс из таких событий и исходов (все матчи чемпионата Италии состоялись 15 мая 2021 года):

Если бы все наши прогнозы оправдались, то сыграл бы коэффициент:2.2 х 3.2 х 3.25 = 22.88

Таким образом, поставив на такое пари 1000 рублей, мы бы получили выплату в 22 880 рублей (1000 х 22.88) с чистой прибылью в 21 880 (22 880 — 1000).

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

Getty Images

Теперь наш экспресс рассчитывается с коэффициентом 1.00 в качестве третьего множителя:2.2 х 3.2 х 1.00 = 7.04

Выплата с тысячи теперь составляет 7040, а чистая прибыль — 6040.

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

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

Возьмём для нашего третьего матча вместо Ф1 (+1) другой показатель — Ф1 (+1.25) с коэффициентом 2.50.

Теперь наша поставленная тысяча рублей делится на два экспресса по 500 рублей. В первом для третьего матча идёт Ф1 (+1), а во втором Ф1 (+1.5).

Получается в первом возврат, а во втором — полный выигрыш. В варианте с возвратом мы знаем итоговый коэффициент — 7.04:

7.04 х 500 = 3520

Плюс считаем с новым коэффициентом полностью выигранный тройник:

2.2 х 3.2 х 2.5 х 500 = 8800

Общая выплата:

3520 + 8800 = 12 320 рублей.

Getty Images

А если бы мы поставили на Ф1 (+0.75), то половина нашего экспресса, то есть 500 рублей, просто сгорели бы. Проиграла бы ставка, в которой учитывалась бы Ф1 (+ 0.5). А вторая половина рассчиталась бы следующим образом:

2.2 х 3.2 х 1 х 500 = 3520 рублей

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

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

Преимущества включения в экспресс исхода с возможным возвратом

В качестве итога подчеркнём главные преимущества использования ставок с вероятным возвратом. Первое состоит в элементе подстраховки. Мы берём более низкий коэффициент, но задействуем более вероятный исход. Например, ставим не на тотал больше 2.5 гола, а на ТБ 2.25 или даже на ТБ 2.

Другой плюс в обратном действии, которое включает риск возврата, но существенно повышает коэффициент. Здесь иллюстрация такая: вместо тотала больше 2.5 мяча применяем ТБ 2.75 или ТБ 3. В большинстве случаев коэффициенты сильно возрастают.

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

Автор оригинала: Zell Liew.

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

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

Давайте начнем с синхронных ошибок.

Обработка синхронных ошибок

Если вы хотите обрабатывать синхронную ошибку, вы можете бросить Ошибка в обработчике экспресс-запроса. (Примечание: обработчики запросов также называются контроллерами. Я предпочитаю говорить обработчики запроса, потому что они явные и легко понимать).

app.post('/testing', (req, res) => {
  throw new Error('Something broke! 😱')
})

Эти ошибки могут быть пойманы с экспресс-обработчиком ошибок. Если вы не написали пользовательский обработчик ошибок (подробнее об этом ниже), Express будет обрабатывать ошибку для вас обработчиком ошибок по умолчанию.

Обработчик ошибок Express по умолчанию будет:

1. Установите статус HTTP на 500
2. Отправляет текстовый ответ на запрос
3. Журнал текстового ответа в консоли

Обработка асинхронных ошибок

Если вы хотите обрабатывать асинхронную ошибку, вам нужно отправить ошибку в оперативный обработчик Express через Следующий аргумент

app.post('/testing', async (req, res, next) => {
  return next(new Error('Something broke again! 😱'))
})

Если вы используете Async/ждут в приложении Express, вы хотите использовать функцию обертки, как Express-Async-Handler Отказ Это позволяет писать асинхронный код без пробных блоков. Я писал больше об этом в « », используя Async/ждут в Express “.

const asyncHandler = require('express-async-handler')

app.post('/testing', asyncHandler(async (req, res, next) => {
  // Do something
}))

Как только вы завернули обработчик запроса с Express-Async-Handler , ты можешь бросить Ошибка как раньше, и она будет обрабатываться с оперативным обработчиком ошибок.

app.post('/testing', asyncHandler(async (req, res, next) => {
  throw new Error('Something broke yet again! 😱')
}))

Написание пользовательского обработчика ошибок

Экспресс обработчики ошибок принимают четырех аргументов:

Они должны быть размещены после всех ваших подразгоний и маршрутов.

app.use(/*...*/)
app.get(/*...*/)
app.post(/*...*/)
app.put(/*...*/)
app.delete(/*...*/)

// Place your error handler after all other middlewares
app.use((error, req, res, next) => { /* ... */ })

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

1. Отправить на действительный код состояния HTTP
2. Отправить действительный ответ

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

1. 400 неплохой ошибка запроса:

• Используется, когда пользователь не содержит поле (например, информации о кредитной карте в форме оплаты)
• Также используется, когда пользователь вводит некорректную информацию (пример: вводит различные пароли в полевом поле пароля и подтверждение пароля).

1. 401 Несанкционированная ошибка: Используется, когда пользователь входит в неверную информацию для входа (например, имя пользователя, электронное письмо или пароль).
2. 403 Запрещенная ошибка: Используется, когда пользователь не допускается доступа к конечной точке.
3. 404 не найден ошибка: Используется, когда конечная точка не найдена.
4. 500 Внутренняя ошибка сервера: Используется запрос, отправленный Frontend, является правильным, но произошла ошибка с бэкэнда.

Как только вы определили правильный код состояния HTTP, вы хотите установить статус с помощью res.status.

app.use((error, req, res, next) => {
  // Bad request error
  res.status(400)
  res.json(/* ... */)
})

Код состояния HTTP должен соответствовать сообщению об ошибке. Для кода состояния соответствует сообщению об ошибке, необходимо отправить код состояния вместе с ошибкой.

Самый простой способ – использовать http-errors упаковка. Это позволяет отправлять три вещи в свои ошибки:

1. Код состояния
2. Сообщение для перехода с ошибкой
3. Любые свойства, которые вы хотели бы отправить. Это необязательно.

Установка http-errors :

npm install http-errors --save

Использование http-errors :

const createError = require('http-errors')

// Creating an error
throw createError(status, message, properties)

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

Когда вы создаете ошибку, вы хотите:

1. Отправьте ошибку 400 плохой запроса (потому что пользователь заполнен неверной информацией). Вы отправляете это как первый параметр.
2. Отправить сообщение, которое говорит «Пользователь не найден». Вы отправляете это как второй параметр.

app.put('/testing', asyncHandler(async (req, res) => {
  const { email } = req.body
  const user = await User.findOne({ email })

  // Throws error if user not found
  if (!user) throw createError(400, `User '${email}' not found`)
}))

Вы можете получить код статуса с Ошибка .status и сообщение об ошибке с Error.message Отказ

// Logging the error
app.use((error, req, res, next) => {
  console.log('Error status: ', error.status)
  console.log('Message: ', error.message)
})

Затем вы установили статус ошибки с помощью res.status Отказ Вы отправляете сообщение на res.json Отказ

app.use((error, req, res, next) => {
  // Sets HTTP status code
  res.status(error.status)

  // Sends response
  res.json({ message: error.message })
})

Лично я люблю отправлять статус, сообщение и трассировку стека для меня легко отладки.

app.use((error, req, res, next) => {
  // Sets HTTP status code
  res.status(error.status)

  // Sends response
  res.json({
    status: error.status,
    message: error.message,
    stack: error.stack
  })
})

Запасной код состояния

Если ошибка не возникла из CreateError он не будет иметь свойство статуса.

Вот пример. Допустим, вы пытались прочитать файл с Fs.readfile , но файл не существует.

const fs = require('fs')
const util = require('util')

// Converts readFile from callbacks to Async/await.
// Find out how to do this here: https://zellwk.com/blog/callbacks-to-promises
const readFilePromise = util.promisify(fs.readFile)

app.get('/testing', asyncHandler(async (req, res, next) => {
  const data = await readFilePromise('some-file')
})

Эта ошибка не будет содержать Статус имущество.

app.use((error, req, res, next) => {
  console.log('Error status: ', error.status)
  console.log('Message: ', error.message)
})

В этих случаях вы можете по умолчанию до 500 внутренней ошибки сервера.

app.use((error, req, res, next) => {
  res.status(error.status || 500)
  res.json({
    status: error.status,
    message: error.message,
    stack: error.stack
  })
})

Изменение состояния ошибки

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

В этом случае вы хотите использовать попробуйте/поймать Чтобы поймать оригинальную ошибку. Тогда вы воссоздаете ошибку с CreateError Отказ

app.get('/testing', asyncHandler(async (req, res, next) => {
  try {
    const { file } = req.body
    const contents = await readFilePromise(path.join(__dirname, file))
  } catch (error) {
    throw createError(400, `File ${file} does not exist`)
  }
})

Обработка 404 ошибок

Конечная точка не найдена, если запрос падает через все ваши подразнения и маршруты.

Чтобы обработать не обнаруженное ошибку, вы вставляете промежуточное программное обеспечение между маршрутами и обработчиком ошибок. Здесь создайте ошибку с CreateError Отказ

// Middlewares...
// Routes...

app.use((req, res, next) => {
  next(createError(404))
})

// Error handler...

Что касается «не может установить заголовки после их отправки клиенту»

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

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

1. res.send.
2. res.json.
3. res.render.runder.
4. res.sendfile.
5. Res.sendstatus.
6. Отправить
7. res.redirect.

Например, если вы запустите res.render и res.json В том же обработчике ответа вы получите «Невозможно установить заголовки после отправки» ошибки.

app.get('/testing', (req, res) => {
  res.render('new-page')
  res.json({ message: '¯_(ツ)_/¯' })
})

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

При потоковой передаче

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

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

app.use((error, req, res, next) => {
  // Do this only if you're streaming a response
  if (res.headersSent) {
    return next(error)
  }

  // Rest of the error handlers
})

Это все, что я знаю сейчас!

Спасибо за прочтение. Эта статья была первоначально опубликована на мой блог Отказ Подпишись на Моя рассылка Если вы хотите больше статей, чтобы помочь вам стать лучшим разработчиком Frontend.