Почему ошибка javascript

Автоматически генерируемые ошибки JavaScript – почему они происходят

Первый шаг к пониманию ошибок JavaScript – разобраться, откуда они берутся. Большинство ошибок JavaScript, встречающихся в природе, автоматически генерируются самим движком JavaScript. Существует множество типов ошибок, но, как правило, все они относятся к одному из трех классов.

TypeError

Один из наиболее распространенных классов ошибок. Такая ошибка возникает, когда некоторое значение относится не к тому типу, к которому должно относиться. Часто это возникает, когда код вызывает как функцию некоторую сущность, функцией не являющуюся. Это может быть неопределенное (“undefined”) или какое-нибудь другое значение.

window.foo()
  // => TypeError: window.foo это не функция
[].length
  // => 0
[].length()
  // => TypeError: array.length это не функция

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

window.foo.bar
  // => TypeError: Невозможно прочитать свойство 'bar' у undefined

SyntaxError

Эти ошибки возникают, когда движок JavaScript разбирает скрипт и встречает синтаксически неверный код. Если в файле JavaScript содержится синтаксическая ошибка, то никакой код из него не выполнится.

 console.log('hello')
    notValid(

Мало того, что этот код выдаст ошибку, но и console.log перед неверным кодом даже не запустится.

ReferenceError

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

console.log(somethingMadeUp)
  // => ReferenceError: somethingMadeUp не определено

Выбрасывание ошибок вручную

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

Простейший способ вручную спровоцировать ошибку – при помощи оператора throw:

throw 'Invalid input';

В таком случае автоматически создается экземпляр объекта Error с сообщением “Invalid input”, но экземпляр ошибки также можно создать вручную и передавать его в коде.

let error = new Error('Invalid input')
  // позже
throw error;

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

function sayName(name) {
  if(typeof name !== 'string') {
    throw new Error('name must be a string, received:' + typeof name);
  }
}

Перехват ошибок в блоке try/catch

Если вы знаете, что конкретный блок кода устроен рискованно и может выбрасывать ошибку, то эту ошибку можно обернуть в блок try/catch.

try {
  someCrashyFunction()
} catch(error) {
  //  может быть, отобразить это пользователю
  // и сообщить об ошибке разработчику
  Bugsnag.notify(error);
}

Блоки try/catch также можно вкладывать друг в друга. Как только ошибка будет обработана, желательно передать ее выше по стеку вызовов, чтобы там она могла быть выброшена повторно.

try {
  someCrashyFunction()
} catch(error) {
  // Обработать ошибку здесь:
  // ...
  // а затем передать вверх по цепочке
  throw error;
}

Давайте включим глобальную обработку ошибок и выловим их все

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

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

Чтобы выловить и обработать все ошибки JavaScript, которые могут возникнуть в браузерном сеансе, можно прибегнуть к обработчику событий window.onerror. Так можно задать глобальный обработчик для всех необработанных ошибок, которые могли бы всплыть в коде. Именно такое событие применяется в библиотеке Bugsnag для сообщения о неотловленных ошибках в браузерных JavaScript-приложениях.

В среде Node нет объекта window, поэтому аналогичный функционал связан с использованием process.on(‘unhandledException, callback).

Глобальная обработка ошибок не может заменить детализированного контроля, который достигается при помощи операторов try/catch. Глобальная обработка ошибок применяется только для подстраховки в качестве средства от тех исключений, которые проскользнут через передовые линии защиты. Устраивая обработку ошибок ближе к источнику потенциальной проблемы, мы, пожалуй, будем лучше представлять, как справиться с ошибкой и как восстановиться после нее еще до того, как пользователь заметит проблему. А если ошибка и проползет через какую-нибудь щель, то мы можем спокойно рассчитывать на то, что глобальный обработчик ошибок все равно предъявит нам возникшие проблемы.

Неисправные промисы

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

fetch('https://my-api.endpoint')
.then((response) => {
  response.thisMethodDoesNotExist() // эта ошибка будет поглощена

  doSomethingElse() // этот код никогда не будет выполнен
})

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

fetch('https://my-api.endpoint')
  .then((response) => {
      response.thisMethodDoesNotExist()
    doSomethingElse() // этот код никогда не будет выполнен
  })
  .catch((error) => {
    console.error(error)
    // # => response.thisMethodDoesNotExist это не функция
    Bugsnag.notify(error)
    // показать ошибку пользователю
  });

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

window.addEventListener("unhandledrejection", (event) => {
  console.error(event.reason);
  // здесь сообщаем об ошибке
});

Теперь любой отказавший промис, у которого нет явного обработчика catch, спровоцирует событие unhandledrejection.

Свойства ошибки

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

   let error = new Error('This is my message')
    console.log(error.message)
    // => это мое сообщение

По умолчанию ошибка имеет то же имя, что и функция конструктора. Поэтому, когда ошибка создается при помощи новой Error(‘oh no!’) или throw(‘oh no!’), она называется “Error”. Если создать ошибку при помощи новой TypeError(‘oh no!’), то она будет называться “TypeError”. Имя ошибки можно переопределить, просто установив другое имя.

   let myError = new Error('some message');
    myError.name = 'ValidationError';
    throw myError;

Здесь мы переименовали ошибку в ValidationError, и, например, в дашборде Bugsnag это будет отражено. Но некоторые браузеры (напр., Chrome), все равно будут выводить в консоль просто “Error”. Чтобы справиться с этой проблемой, можно применять пользовательские классы ошибок, о которых мы поговорим ниже в этой статье.

Стектрейсы

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

Важно отметить, что структура стектрейса зависит от того, где была инициализирована ошибка, а не где она выброшена. Таким образом, если ошибка создается в functionA и возвращается от нее, а затем выбрасывается в functionB, то на вершине стектрейса будет functionA.
Вполне вероятно, что вы минифицируете ваш код JavaScript. В таком случае строки в стектрейсе не будут совпадать со строками в оригинальном файле с исходным кодом. Чтобы найти оригинальный исходный код, используются специальные карты исходников, по которым стектрейс можно отыскать и «перевести». Об этом рассказано в статье the Anatomy of source maps.

Создание пользовательских типов ошибок

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

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

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

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

class ValidationError extends Error {
  constructor(field, reason) {
    super(reason);
    this.field = field;
    this.reason = reason;
    // следующая строка важна, так как сообщает, что конструктор ValidationError
    // не входит в состав результирующего стектрейса
    Error.captureStackTrace(this, ValidationError);
  }

 // также в этом классе можно определить пользовательские методы
  prettyMessage() {
     return `ValidationError: [${this.fields}] reason: ${this.reason}`;
     // исключение: "ValidationError: [age] причина: должно быть числом"
  }
}

Затем код ошибки может воспользоваться instanceof, чтобы определить, ошибка какого типа была выброшена, и отреагировать соответствующим образом. Например, в приложении на Express.js это достижимо при помощи специализированного промежуточного ПО.

app.use(function errorHandler (error, req, res, next) {
 if (error instance of ValidationError) {
   // выдать в ответ код 400 и включить важные детали об ошибке 
   return res.status(400).json({
      type: error.name,
      message: error.prettyMessage(),
      field: error.field,
    });
  } else {
    // Это ошибка другого рода, пусть с ней разберется обработчик ошибок, заданный по умолчанию 
    next(error)
  }
})

Хотя в этом примере и используется промежуточное ПО из Express.js, подобный подход применим и в других разновидностях приложений JavaScript, с использованием обычного try/catch.

try {
  submitForm();
} catch (error) {
  if (error instanceof ValidationError) {
    // показать ошибку пользователю
    displayErrorMessage(error.prettyMessage());
  } else {
    // передать ее обработчику ошибок, заданному по умолчанию
    throw error;
  }
}

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

Заключение

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

P.S.

На сайте издательства продолжается осенняя распродажа.

От автора: чтобы вернуть сообщество разработчиков, мы рассмотрели нашу базу данных по тысячам проектов и нашли 10 самых распространённых ошибок в JavaScript. Мы собираемся показать вам, что к ним приводит и как это предотвратить. Если ни одна ошибка JavaScript не встречается в вашем коде, это делает вас лучшим разработчиком.

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

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

Вот первые 10 ошибок JavaScript:

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

1. Uncaught TypeError: Cannot read property

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

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

Здесь понимаются две важные вещи:

Это легко исправить. Самый простой способ: инициализировать состояние с разумными значениями по умолчанию в конструкторе.

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

2. TypeError: ‘undefined’ is not an object (evaluating

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

3. TypeError: null is not an object (evaluating

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

Интересно, что в JavaScript значения null и undefined не совпадают, поэтому мы видим два разных сообщения об ошибках. Undefined обычно является переменной, которая не была назначена, а null означает, что значение пустое. Чтобы убедиться, что они не одно и то же, попробуйте использовать строгий оператор равенства:

Один из способов, которым эта ошибка может возникнуть в реальном мире — это попытка использовать элемент DOM в JavaScript перед загрузкой элемента. Это потому, что DOM API возвращает null для ссылок на пустые объекты.

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

В этом примере мы можем решить проблему, добавив прослушиватель событий, который уведомит нас, когда страница будет готова. После addEventListener метод init() может использовать элементы DOM.

4. (unknown): Script error

Ошибка скрипта возникает, когда ошибка неперехваченного JavaScript пересекает границы домена и нарушает политику перекрестного происхождения. Например, если вы размещаете свой код JavaScript на CDN, любые неперехваченные ошибки (ошибки, которые появляются в обработчике window.onerror, вместо того, чтобы быть пойманным в try-catch) будут переданы как просто «Script error» вместо того, чтобы содержать полезную информацию. Эта мера безопасности браузера предназначена для предотвращения передачи данных по доменам, которые в противном случае не были бы допущены к коммуникации.

Чтобы получить реальные сообщения об ошибках, выполните следующие действия:

1. Отправьте заголовок Access-Control-Allow-Origin

Установка заголовка Access-Control-Allow-Origin в * означает, что к ресурсу можно получить доступ из любого домена. Вы можете заменить * своим доменом, если необходимо: например, Access-Control-Allow-Origin: www.example.com . Если вы используете CDN из-за проблем с кэшированием, которые могут возникнуть, обработка нескольких доменов становится сложной и нельзя не приложить усилий. Подробнее см. здесь.

Вот несколько примеров того, как установить этот заголовок в различных средах:

Apache

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

Nginx

Добавьте директиву add_header в блок местоположения, который служит файлам JavaScript:

HAProxy

Добавьте в ресурс, где будут загружены файлы JavaScript:

2. Установите crossorigin = «anonymous» в теге скрипта

В HTML-источнике для каждого из сценариев, где вы установите заголовок Access-Control-Allow-Origin, в теге SCRIPT установите crossorigin=»anonymous». Убедитесь, что заголовок отправляется для файла сценария, перед добавлением свойства crossorigin в тег скрипта. В Firefox, если атрибут crossorigin присутствует, но заголовок Access-Control-Allow-Origin отсутствует, сценарий не будет выполнен.

5. TypeError: Object doesn’t support property

Это ошибка, которая возникает в IE при вызове неопределенного метода. Вы можете проверить это в IE Developer Console.

Это эквивалентно ошибке «TypeError: ‘undefined’ is not a function» в Chrome. Да, разные браузеры могут иметь разные сообщения для одной и той же ошибки.

Это обычная проблема для IE в веб-приложениях, использующих пространство имен JavaScript. Когда это так, проблема в 99,9% случаев— это неспособность IE связать методы в текущем пространстве имен с ключевым словом this. Например, если у вас есть пространство имен имен Rollbar с помощью метода isAwesome. Обычно, если вы находитесь в пространстве имен Rollbar вы можете вызвать метод isAwesome со следующим синтаксисом:

Chrome, Firefox и Opera с радостью согласятся с этим синтаксисом. С другой стороны, IE не станет. Таким образом, самая безопасная ставка при использовании JS namespacing — это префикс с фактическим пространством имен.

6. TypeError: ‘undefined’ is not a function

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

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

Рассмотрим фрагмент кода:

Выполнение вышеуказанного кода приводит к следующей ошибке: «Uncaught TypeError: undefined is not function». Причина, по которой вы получаете эту ошибку, заключается в том, что при вызове setTimeout() вы вызываете window.setTimeout(). В результате анонимная функция, передаваемая setTimeout(), определяется в контексте объекта окна, у которого нет clearBoard().

Традиционное решение, совместимое со старым браузером — просто сохранить ссылку на this в переменной, которая затем может быть унаследована закрытием. Например:

Кроме того, в новых браузерах для передачи правильной ссылки вы можете использовать метод bind():

7. Uncaught RangeError: Maximum call stack

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

Это также может произойти, если вы передадите значение функции, находящейся за пределами допустимого диапазона. Многие функции принимают только определенный диапазон чисел для своих входных значений. Например, Number.toExponential(digits) и N umber.toFixed(digits) принимают цифры от 0 до 20, а Number.toPrecision(digits) принимают цифры от 1 до 21.

8. TypeError: Cannot read property ‘length’

Это ошибка, которая возникает в Chrome из-за свойства длины чтения для неопределенной переменной. Вы можете протестировать это в консоли разработчика Chrome.

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

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

У вас есть два способа решить эту проблему:

1. Удалите параметры в объявлении функции (оказывается, вы хотите получить доступ к тем переменным, которые объявлены вне функции, поэтому вам не нужны параметры для вашей функции):

2. Вызовите функцию, передав ей массив, который мы объявили:

9. Uncaught TypeError: Cannot set property

Когда мы пытаемся получить доступ к неопределенной переменной, она всегда возвращает undefined, а мы не можем получить или установить любое свойство undefined. В этом случае приложение будет выбрасывать “Uncaught TypeError cannot set property of undefined.”

Например, в браузере Chrome:

Если объект test не существует, будет выдаваться ошибка: “Uncaught TypeError cannot set property of undefined.”

10. ReferenceError: event is not defined

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

Если вы получаете эту ошибку при использовании системы обработки событий, убедитесь, что вы используете объект события, переданный в качестве параметра. Старые браузеры, такие как IE, предлагают событие глобальной переменной, но не поддерживаются во всех браузерах. Библиотеки, подобные jQuery, пытаются нормализовать это поведение. Тем не менее, лучше использовать тот объект, который передается в функцию обработчика событий.

Вывод

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

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

Автор: Jason Skowronski

Источник: //rollbar.com/

Редакция: Команда webformyself.

Is this article up to date?