- отсутствие консоли в некоторых мобильных и планшетных браузерах;
- открытая консоль мешает при тестировании, перекрывая видимую часть страницы;
- консоль открывают когда страница уже загрузилась и ошибки, возникающие при загрузке, теряются (Firebug в Firefox, Internet Explorer);
- при разработке часто отключают логирование ошибок в системах аналитики, чтобы не было лишнего «шума» при анализе ошибок;
- и прочее.
Для решения проблемы я написал небольшой js-скрипт «show-js-error», который выводит приметное сообщение о js-ошибке при её возникновении в браузере.
На показе сообщений всё не заканчивается, важно зарепортить ошибку. Правильное описание бага — починка половины бага.
Для этого в задаче на исправление бага необходимо указать информацию:
- описание и тип ошибки;
- stack trace или имя файла с номером строки;
- адрес страницы;
- referrer;
- ОС и её версия;
- браузер и его версия;
- и т.д.
Чтобы каждый раз не тратить время, воспользуемся кнопкой «Copy» для копирования всей информации об ошибке в буфер обмена. Или кнопкой «Send», заведение бага с которой занимает всего один клик.
Правда, для Github?а понадобится два клика — клик на кнопку «Send» в сообщении и «Submit new issue» на самом Github'е.
При заведении нового Issue, заголовок и текст сообщения можно пробросить через GET-параметры.
https://github.com/hcodes/show-js-error/issues/new?title=My%20title&body=My%20text
Быстрый старт
Устанавливаем:
npm install show-js-error
Подключаем на свою страницу в <head> перед всеми скриптами:
<link rel="stylesheet" href="./node_modules/show-js-error/dist/show-js-error.css" />
<script src="./node_modules/show-js-error/dist/show-js-error.js"></script>
Также можно показывать ошибки другого типа, например, ошибки с сервера, проброшенные на страницу:
showJSError.show({
title: 'Server error',
message: 'My message',
stack: 'My stack'
});
В итоге:
- меньше ошибок в проде;
- «лечим» ошибки при разработке, а не в проде;
- быстро и четко ставим задачи на починку багов;
- упрощаем жизнь тестировщикам.
Ссылки:
Комментарии (28)
alex_blank
26.03.2016 23:27+6Я когда-то давно сделал Panic.js для того же самого, но все никак руки не дойдут написать статью.
Тут ловятся непойманные исключения, парсится коллстек и загружаются исходники, разворачиваемые по клику:
Eugeny1987
28.03.2016 00:17в Opera 12 только не работает (
i.imgur.com/b65wveY.pngalex_blank
31.03.2016 11:44Видимо, там другой формат колл-стека, надо в этот модуль дописать его парсер:
https://github.com/xpl/useless/blob/master/base/reflection.js
Не обещаю, что это удастся сделать в обозимом будущем, но спасибо за репорт.
kemsky
28.03.2016 03:57125 кб + зависимости, к большому сожалению.
alex_blank
31.03.2016 11:41Это не для использования на продакшене — а для дебага лишняя сотня кб не проблема. Оно еще и вешает хук на все коллбеки EventTarget, поэтому страдает производительность (теоретически). Дело в том, что это не stand-alone инструмент, а часть здорового фреймворка, который оно весь тянет за собой. В будущем я хочу отделить его в самостоятельный проект, с минимумом зависимостей, тогда размер будет маленький. Собственно, это та причина, по которой это нигде особо не публиковалось пока.
arty
26.03.2016 23:28+4markusweb
27.03.2016 14:58+1Rollbar — есть бесплатный план.
arty
27.03.2016 14:59+2сервер Sentry можно вообще на свою машину установить, это вроде бы единственное open-source решение
leoismyname
27.03.2016 17:28Можно, кстати, отказаться от использования Sentry и использовать отдельно реализацию Raven JavaScript, указать свой эндпоинт в настройках, затем ловить то, что будет приходить :)
serf
27.03.2016 12:09+1Вот это можно было бы использовать как солидный парсер stacktrace (там есть всякие нюансы, кросс браузерность и тд) https://github.com/stacktracejs/stacktrace.js В принципе эта либа + простейший UI и библиотека не нужна.
alex_blank
27.03.2016 17:24В Safari есть такая проблема, что в onerror не передается объект Error, поэтому вы не сможете получить коллстек в unhandled exception listener'е.
В Panic.js упомянутом выше это обходится с помощью следующего work-around: поскольку практически весь реальный код выполняется внутри какого-либо колбека (setTimeout, addEventListener и т.п.), и таких «точек входа» не так много, то можно их все заврапить в try/catch:
https://github.com/xpl/useless/blob/master/base/uncaught.js
https://github.com/xpl/useless/blob/master/base/uncaughtAsync.js
Дополнительно это дает возможность строить асинхронные колл-стеки. Что забавно, хромовский веб-инспектор именно такие стеки и показывает, но при этом в объект Error передается «обычный» урезанный стек, без асинхронного контекста. Это фейл. Собственно, Panic.js позволяет получать полный стек на любой платформе, вне зависимости от прихотей браузера.
Что интересно, это позволяет пойти еще дальше — можно пробрасывать в AJAX-запросах серверный стек, и получать «сквозную» трассировку, с непрерывным стеком клиента и сервера, как будто и нет никакого разделения:
alex_blank
27.03.2016 17:28Для Node.js там реализован няшный текстовый принтер эксепшенов, тоже со строками кода и табличным форматированием:
vitalets
28.03.2016 11:03А умеет Panic.js отлавливать непойманные режекты в промисах?
Кажется, что пока onunhandledrejection не будет доступно в браузерах, сделать это проблематично.
FrozenInternet
28.03.2016 00:17Почему бы не добавить пакет в bower, раз инструмент используется в браузерах и на клиентах?
Так гораздо проще будет пользоваться тем, кто настроил клиентский инжект на страницу :)
vitalets
28.03.2016 11:00Хороший модуль. Кстати в дефолтную поставку можно добавить отпарвку ошибки в гугл аналитикс. Это самое простое решение, про него уже несколько раз писали на хабре.
hcodes
28.03.2016 12:59А почему GA, а не Метрику?
Цель у show-js-error лишь одна — выводить приметное сообщение при возникновении js-ошибки.
Pilat
npm install — как современно то…
ivaaaan
Сарказм? Чем вам не угодил npm?
DevGood
Ух как интересно стало — что не так с npm? Сначало даже подумал, что пропустил рождение новой звезды — но нет, nodejs все еще использует и поставляется с npm.
monolithed
Суть претензии в этом?
Pilat
Именно в этом.
monolithed
Проблема даже не в самом npm, а registry (хранилище пакетов).
В таком случае, никаких претензий не будет, поскольку все файлы будет храниться в том месте где вам удобно.
Также есть IPFS...
taliban
То что другие используют идиотский подход при разработке пакетов, совершенно не значит что сама идея пакетов плоха, и не нужно их использовать.