Pull to refresh

Comments 43

Напоминает страницу ошибок в ASP. Тока здесь куда притней глазу.
В ASP.net это кастомизируется не в пример легче. И выдача ошибок только локальному клиенту делается одной строчкой ;)
вывод ошибок - не главная задача веб-технологий. против ASP я, конечно, ни чего против не имею
два раза "против" :-[
да, я дурак(
Ну, это так было, чисто в ответ на "приятней глазу" — для более корректного сравнения возможностей платформ.
Согласен, приятней, но что-то не заметил на скриншоте стек трейса, а чтука очень полезная.
На скриншоте все пароли и пассы наружу - раздолье для весёлых хацкеров.
Backtrace выдаётся только на машине с IP=127.0.0.1
Усё предусмотрено. ^_^
а вы знаете, что на некоторых хостингах REMOTE_ADDR всегда содержит 127.0.0.1? говорю как человек, который их видел ну очень много.
дауж, подтверждаю, так как встречался и не раз!
Ну ладно вам, ладно… Не всё же с первого раза должно получаться :-) Как вам такой вариант: $_SERVER['SERVER_ADDR'] == $_SERVER['REMOTE_ADDR']?
В большинстве современных нормальных фреймворках существует такое понятие, как environment. В отличие от development environment, в production environment никаких ошибок не должно отображаться в принципе, кому бы то ни было, а писать надо всё в логи.
не, серьезно. на REMOTE_ADDR завязываться не стоит. приведу пример: у нас apache на заднем конце, а nginx на переднем. допустим, кое-что забыли подкрутить и ip клиента всегда будет равен ip сервера. т.е. в конечном счете SERVER_ADDR == REMOTE_ADDR. вот такое вот бывает.
есть еще разные варианты. например, если у вас сервис типа http://translate.google.ru/translate_t?h…. запрашиваем в нем самого себя и опять таки SERVER_ADDR == REMOTE_ADDR. etc.
Короче, крутите тогда сами… ;-) Вообще в оригинальной версии класса $_SERVER['SERVER_ADDR'] == $_SERVER['REMOTE_ADDR'] определяет показывать ли backtrace, если других инструкций не дано (считывается переменная окружения Aero()->get_option('show_backtrace', $is_localhost, 'error_handler'); если она выставлена в false ничего выводиться не будет). Я не даром упомянул MIT: делайте, что хотите, но меня не вините…
Если на сайте есть разделение прав, то луше показывать администратору, а для гостей логировать.
а если ошибка возникает только у гостей? ;)
блин, это же мой айпишник!
так нефиг для кого не попало лог показывать
Молодец нужное для себя дело сделал, а вот как их оформлять это уже дело персонально каждого программиста.
Почитай так же про FirePHP, сейчас ею пользуюсь вовсю
Это отдельный класс AeroLogger уже в разработке. Вместе с профайлером и "консолью" для остальных браузеров.
UFO just landed and posted this here
Лучше, конечно, никогда (даже такие) сообщения об ошибках не видеть :)

Спасибо за оригинальный код и его лицензию!

// Плюс топику и карме.
>Прочитав недавно на пьяную голову «Обработка ошибок и исключений в PHP»
Вот эта фраза, мне кажеться, заслуживает внимания.
«Код-то где, балаболка?» - вобще класс!!!
> Код релизится под MIT-лицензией.
Лол :)
UFO just landed and posted this here
Update: Немного отрезвев от пятничного пива, я задумался… А нафигом мне тут исключения? 0_o

Как автор топика, на который вы ссылаетесь, позволю себе прокомментировать необходимость (на мой взгляд) исключений:
если вы вызываете несколько функций (или методов) подряд, причем одну функцию из другой, то при использовании исключений код не будет выполняться за той точкой, в которой произошла ошибка. Если использовать просто связку set_error_handler-trigger_error, то код будет выполняться дальше.
Например:

<?
error_reporting
(E_ALL);

function 
a() {
    echo 
"This is function A<br />";
    
trigger_error('<b>Error!!!!!!!!!!!!!!!!!!!</br /></b>');
    
b();
}

function 
b() {
    echo 
"This is function B<br />";
}

function 
err($code$msg ''$file ''$line 0) {
    echo 
"This is error: ".$msg;
}

set_error_handler('err'E_ALL);
a();
?>

В этой ситуации при возникновении ошибки (точнее сигнале со стороны вашего приложения об ошибке) код продолжит выполняться и скрипт выведет на экран:

This is function A
This is error: Error!!!!!!!!!!!!!!!!!!!
This is function B

Если генерировать Exception, то до строки с вызовом b() интерпретатор не дойдет. Как поступать, решать каждому в отдельности.

И тут моя позиция такова: для notice показываем ваши красивости, но выполнение продолжаем, а для warning - красивости и останов приложения.
Я после генерации критической ошибки тупо давлю exit(). ;-) Вместо exit(), можно кинуть какое-нибудь исключение, если нужно корректно убить все объекты, вызывая деструкторы. IMHO дело вкусу. Лично я на деструкторы стараюсь не полагаться.
В django тоже красиво очень, а в django-book так и написано "надеюсь вам понравятся наши постельные тона" :-)
Наверное меня щас заминусуют, но... нафига? :) Хороший код должен работать без ошибок и исключений в продакшне. Т.е. фактически, ни перехват, ни оформление не нужны :)
ну то, что сделал автор — некий фетиш :)
а вообще какой-бы ты не был крутой программер — ошибки все-равно будут
Зачем пугать пользователей вот такими дампами?
… все должно быть тихо мирно и, главное, недоступно для левых глаз
Rails — framework. Тут же предлагается standalone-решение.
И почему ребята из PHP сами такого не сделали?
Интересно, а как раньше вы дебагали свои творения? :)
О проектах с такими вложениями в народе будут говорить: «сайт говно, но какие ошибки выдает, залюбуешься» :)
А зеркала не осталось?
Только руки дошли, захотелось попробовать, а тут такое вот дело.
Сейчас ссылка недоступна.
Sign up to leave a comment.

Articles

Change theme settings