[javascript]
$rootScope.$on(‘$stateChangeError’, function(event, toState, toParams, fromState, fromParams, error){
console.error(error);
});
[/javascript]

and now wow! we have an exact error in console and no need to guess what’s wrong with your code anymore.

[javascript]
// Credits: Adam`s answer in http://stackoverflow.com/a/20786262/69362
var $rootScope = angular.element(document.querySelectorAll(‘[ui-view]’)[0]).injector().get(‘$rootScope’);

$rootScope.$on(‘$stateChangeStart’,function(event, toState, toParams, fromState, fromParams){
console.log(‘$stateChangeStart to ‘+toState.to+’- fired when the transition begins. toState,toParams : \n’,toState, toParams);
});

$rootScope.$on(‘$stateChangeError’,function(event, toState, toParams, fromState, fromParams){
console.log(‘$stateChangeError – fired when an error occurs during transition.’);
console.log(arguments);
});

$rootScope.$on(‘$stateChangeSuccess’,function(event, toState, toParams, fromState, fromParams){
console.log(‘$stateChangeSuccess to ‘+toState.name+’- fired once the state transition is complete.’);
});

$rootScope.$on(‘$viewContentLoaded’,function(event){
console.log(‘$viewContentLoaded – fired after dom rendered’,event);
});

$rootScope.$on(‘$stateNotFound’,function(event, unfoundState, fromState, fromParams){
console.log(‘$stateNotFound ‘+unfoundState.to+’ – fired when a state cannot be found by its name.’);
console.log(unfoundState, fromState, fromParams);
});
[/javascript]

if you have you Angular app root on html element you can simply use:

[javascript]
var $rootScope = angular.element(document).scope();
[/javascript]

code is placed here.

It’s easy to do by right click on break point:

and after create extra code:

or it could be console.log:

For more information you could review this video from egghead.

You can add script to the blackbox by right click on file in the source tab:

and the blackbox management is placed in Web Developer settings:

More info on official site.

• своя обертка-заглушка на объект console
• отправка ошибок на сервер
• переопределение обработчика window.onerror
• создание своих классов ошибок
• классификация ошибок
• красивый вывод
• режим отладки

Более подробно о каждом под катом.

Своя обертка-заглушка на объект console

Я думаю вы знаете, что часто для отладки javascript кода и для вывода какой-либо информации в консоль браузера используется объект console.

Так вот, для чего нужно писать для него обертку? Причины следующие:

• вы поддерживать браузеры, которые до сих пор не знакомы с этим объектом – чтобы не возникло ошибок
• вы хотите чтобы после сжатия кода из кода были удалены все вызовы данного объекта

По первому пункту все просто – код будет где-то такой(console + FireBug console):

if (!window.console)
{
    window.console = {
        "assert": function() { },
        "count": function() { },
        "clear": function() { },
        "debug": function() { },
        "dir": function() { },
        "dirxml": function() { },
        "info": function() { },
        "error": function() { },
        "getFirebugElement": function() { },
        "group": function() { },
        "groupEnd": function() { },
        "groupCollapsed": function() { },
        "log": function() { },
        "notifyFirebug": function() { },
        "profile": function() { },
        "profileEnd": function() { },
        "time": function() { },
        "timeEnd": function() { },
        "trace": function() { },
        "warn": function() { },
        "userObjects": [],
        "element": {},
        "firebug": "foo"
    };
};

Более подробно о втором пункте, который не так очевиден. Современные упаковщики-сжимальщики кода уже научились выкидывать ветки и методы, которые никогда не выполнятся:

if(false){
}

будет выкинуто также и

function something(){
    if(false){
    }
}

а самое главное, что даже все вызовы метода something будут также удалены.

Простой пример:

var debug_on = false
function dumpfunc(data)
{
    if (debug_on)
    {
        console.log(data);
    }
}
dumpfunc(5)

Если задать переменную debug равной false, то програма по сжиманию кода выбросит все вызовы метода dump. Это довольно удобно, хотя я бы порекомендовал всеже не держать отладочного кода в репозитории.

Вот тут можно проверить как это работает ( на Advanced режиме).

Отправка ошибок на сервер

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

Также можно продумать вариант отправки ошибок для случая, когда разрывается соединение. В данном варианте мы можем складывать дамп ошибок в локальную базу данный браузера(localStorage), а дождавшись восставноления соединение – отправить все вместе на сервер.

К сожалению, никакой готовой и полноценной библиотеки для сбора и отправки ошибок я не нашел. Если знаете – подскажите пожалуйста в комментариях. То, что частично удовлетворяло требованиям – jQuery.clientSideLogging.

Переопределение обработчика window.onerror

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

Зачем? Представим себе ситуацию: произошла ошибка. Хотим ли мы, чтобы ее обработал браузер и выдал нашему пользователю системное СООБЩЕНИЕ-предупреждение о поломке сайта – не думаю. Ведь намного лучше отловить ошибку, показать пользователю красивый диалог(о том, что в системе что-то пошло не так, но мы это знаем, мы котролируем ситуацию) и не пускать ее дальше на обработку браузера.

Реализовать данный подход в коде мы можем следующим образом:

window.onerror = function (message, source, lineNr) {
//тут идет наш красивый обработчик и логирование ошибки с отравкой на сервер
return true; // а это предотвращение дальнейших действий браузра
};

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

*в данном случае коректнее говорить не об ошибках, а о исключениях (Exceptions).

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

Пример стандартного класса Error, генерируем и ловим ошибку:

try {
    throw new Error("Something goes wrong!");
} catch (e) {
    alert(e.name + ": " + e.message);
}

Создание своего класса(наследуем от Error):

function MyError(message) {
    this.name = "MyError";
    this.message = message || "Default Message";
}
MyError.prototype = new Error();
MyError.prototype.constructor = MyError;
try {
    throw new MyError();
} catch (e) {
    console.log(e.name); // "MyError"
    console.log(e.message); // "Default Message"
}

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

try {
    foo.bar();
} catch (e) {
    if (e instanceof EvalError) {
        alert(e.name + ": " + e.message);
    } else if (e instanceof RangeError) {
        alert(e.name + ": " + e.message);
    }
    // ... etc
}

подробно о объекте Error читать тут.

Классификация ошибок

Тут очень сложно дать общие советы, которые отлично впишутся под структуру всех проектов.

Иногда имеет смысл разделять все ошибки на

• системные – система дальше работать не может, например: разрыв соединения, выход из строя ключевого модуля, синтаксические ошибки
• пользовательские – система может работать дальше, но какой-то модуль отработал некоректно

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

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

• fatal error
• warning
• notice

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

Красивый вывод

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

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

Необходимо определится что мы хотим выводить пользователю и в каком формате. Возможные вариаты:

• модальное окно(modal dialog)
• стиль уведомления(notification)
• встроенные(inline)

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

Режим отладки

Стоит также задуматься над вопросом: хотим ли мы выводить пользователю и разработчку одни и теже ошибки/информацию о проблеме? либо при работе над сайтом и отладке мы хотим получать больше линформации? Мне кажется ответ очевиден – мы хотим чтобы разработчик имел полностью всю информацию: где произошла ошибка и что к этому привело; а для пользователя – ограничиться коротким соощением о технической неполадке.

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

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

1) Работающая функция mail на стороне сервера.

Если не работает – идем сюда /etc/php5/apache2/php.ini и ищем параметр sendmail_path прописываем в него следующее:

sendmail_path = "/usr/sbin/sendmail -t -i"

Да, можно настроить и свой крутой почтовый сервер, но нам пока этого не нужно.

проверим:

<?php mail('somewhere@somemail.com', 'hi', 'your mail works');

Дальше можно накидать свою функцию, которая будет логировать все что мы ее подадим в качестве параметра, что типа:

function mylog( $data )
{
    $dumpData = "\n";
    $dumpData .=  "<pre>";
    $dumpData .= print_r($data, 1);
    $dumpData .=  "</pre>";
    $dumpData .= "<br/><br/><br/>\n\n\n";
    $dumpData .= print_r(debug_backtrace(), 1);
    mail( MAIL_TO, DEBUG, $dumpData );
}

2) Удобный почтовый клиент, который позволит фильтровать полученные логи.

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

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

Почти все разработчики знают, что javascript код можно выполнить прям в строке браузера написав соответственно javascript:[your code here] (например javascript:alert(document.cookie)). Но новые браузеры стали уже блокировать эту возможность, и непосредственный ввод кода может не сработать.

Идем дальше – делаем кнопку: создаем закладку(bookmark), можно просто пустую.

И меняем ей свойство location:

У нас появилась кнопка-закладка, при клике на которую выполнится javascript код.

Дальше уже дело техники. Причем тут мы можем сделать не только включение, но и отключение этой же кнопкой.

UPD: а вот пример кода.