Это правда, что в современных браузерах перехват окон window.onerror для ошибок, которые всплывают до самого верха вместе с добавлением обработчиков событий jQuery для ошибок Ajax, будет ловить практически все объекты Error, добавленные в ваш клиентский код. Если вы вручную настраиваете обработчик для window.onerror, в современных браузерах это делается с помощью window.addEventListener('error', callback)
,
в то время как в IE8 / 9 вам нужно позвонить
window.attachEvent('onerror', callback)
.
Обратите внимание, что вам следует учитывать среду, в которой обрабатываются эти ошибки, и причину этого. Одно дело поймать как можно больше ошибок с их трассировкой стека, но появление современных инструментов разработчика F12 решает этот вариант использования при локальной реализации и отладке. Точки останова и т.д. дадут вам больше данных, чем доступно от обработчиков, особенно для ошибок, выданных сторонними библиотеками, которые были загружены из запросов CORS. Вам необходимо предпринять дополнительные шаги, чтобы дать браузеру указание предоставить эти данные.
Ключевая проблема заключается в предоставлении этих данных в рабочем состоянии, поскольку ваши пользователи гарантированно будут использовать гораздо более широкий набор браузеров и версий, чем вы можете протестировать, и ваш сайт / приложение будет зависать неожиданными способами, независимо от того, сколько QA Вы бросаете на это.
Чтобы справиться с этим, вам необходим производственный трекер ошибок, который выявляет каждую ошибку, возникающую в браузерах вашего пользователя, когда они используют ваш код, и отправляет их в конечную точку, где вы можете просматривать данные и использовать их для исправления ошибок. как они случаются. В Raygun (заявление об отказе от ответственности: я работаю в Raygun) мы приложили немало усилий, чтобы обеспечить для этого большой опыт, так как есть много подводных камней и проблем, которые следует учитывать, что наивная реализация будет отсутствовать.
Например, есть вероятность того, что вы будете связывать и минимизировать свои ресурсы JS, а это означает, что ошибки, генерируемые из минимизированного кода, будут иметь нежелательные трассировки стека с искаженными именами переменных. Для этого вам понадобится ваш инструмент сборки для генерации исходных карт (мы рекомендуем UglifyJS2 для этой части конвейера) и ваш трекер ошибок, чтобы принимать и обрабатывать их, превращая искаженные трассировки стека обратно в удобочитаемые. Raygun делает все это из коробки и включает в себя конечную точку API для принятия исходных карт по мере их создания в процессе сборки. Это ключевой момент, так как их нужно держать закрытыми, иначе любой может уничтожить ваш код, отрицая его назначение.
Клиентская библиотека raygun4js также поставляется с window.onerror
как для современных, так и для старых браузеров, а также с подключаемыми функциями jQuery, поэтому для ее настройки вам нужно всего лишь добавить:
<script type="text/javascript" src="//cdn.raygun.io/raygun4js/raygun.min.js" </script>
<script>
Raygun.init('yourApiKey').attach();
</script>
Существует также множество встроенных функций, включая возможность изменять полезную нагрузку ошибки перед ее отправкой, добавлять теги и пользовательские данные, метаданные для пользователя, который увидел ошибку. Это также избавляет от необходимости получать хорошие трассировки стека из вышеупомянутых сторонних скриптов CORS, которые решают страшную «ошибку скрипта» (которая не содержит сообщений об ошибках и трассировки стека).
Более важной проблемой является то, что из-за огромной аудитории в Интернете ваш сайт будет генерировать тысячи повторяющихся экземпляров каждой ошибки. Служба отслеживания ошибок, такая как Raygun , имеет умения сворачивать их в группы ошибок, чтобы вы не утонули в потоке уведомлений, и позволяет видеть каждую фактическую ошибку, готовую к исправлению.