Developing.ru

Это не реально - стилизировать ошибку при завале апача.. У браузера в этом случае выпадает что сайт не доступе, что-то в этом духе..

Duncon писал(а):Стоит опасаться ошибок не в коде, а в логике программ, они куда серьёзнее и не регистрируются как ошибки..

Согласен, но я не всегда могу предусмотреть крайние точки, когда вываливается ошибка и поэтому использую try {} catch {}. Например, что бы вывести не стандартную страницу 400 page_not_found а оформленную в определенном стиле. Только в заголовок статус записываю нужный =)))

Duncon писал(а):Когда речь заходит об отвале сервиса, клиент в любом случае увидит сообщение от апаче итп. либо ошибку в браузере, на мой взгляд

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

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

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

В общем ходим вокруг качества кода кругами..

Ну, я за советскую власть агитировать никого не собираюсь. Я объяснил как можно использовать try...catch Если ты не планируешь информировать админа об отвале БД, то ты можешь либо по if... else прекращать работу скрипта, либо вовсе забить на возбуждение ошибок, если тебе наплевать на то, в каком виде пользователь увидит информацию об ошибке. Т.е. если тебе UX до лампочки.

Смотри для примера что пишет при отвале базы, полезной инфы 0:

Это предупреждение. Погугли Fatal error: Uncaught exception + название какого-нибудь движка. Ты увидишь много чувствительной информации. Например, имя unix пользователя, название БД, часто запрос, который вызвал ошибку, т.е. будешь не угадывать как выполнить SQL Injection, а точно знать.


И любой мало-мальски популярный и сложный скрипт не будет жить вечно с error_reporting(0) - рано или поздно попадётся конфигурация сервера, на которой скрипт будет молча ничего не делать и пользователь включит error_reporting(-1) .

Чтоб не снабжать error_reporting(0) или вообще на сервере отключается вывод и всё.. Если что произошло смотрим error_log на сервере (во вне он не отдаётся).
Выпиливаю 99% ошибок при отладке, 1% остаётся на внешние причины и они обычно упрятаны в панели управления, связаны с импортом внешних данных типа прайсов итп..

За прошедший год смотрел чего там по логам несколько своих больших сайтов, error_log только по причине отказа БД (обычно с перезагрузкой сервиса связано т.е. вызвана руками).. На простых сайтиках не использую БД, там ошибок 0 "не только лишь всегда" : )

Смотри для примера что пишет при отвале базы, полезной инфы 0:
PHP Warning: mysqli::query(): Couldn't fetch mysqli in /.../sql.php on line 80

Duncon писал(а):например БД отвалилась - продолжение сценария невозможно, опять потерян смысл try cath.. : )

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

Duncon писал(а):Хорошо отлаженный код сообщений не выдаёт..)

Не бывает здоровых людей. Бывают люди недообследованные. Так же и с отлаженным кодом

У меня не бывает критических ошибок и варрингов итп. не бывает.. Если произошёл отказ, то это уже с сервером связано, например БД отвалилась - продолжение сценария невозможно, опять потерян смысл try cath.. : ) Ошибки error_reporting(0), если настолько важные участки с данными при запросе, но они обычно под пользовательской сессией происходят - ну увидит завал клиент и чего? (Это на мой взгляд гипотетическая ситуация сегодня.. Хорошо отлаженный код сообщений не выдаёт..)

try { } catch - вообще не использую, не вижу смысла.

Смысл простой - продолжение работы скрипта при возникновении критической ошибки.

А перехват ошибок нужен, чтобы выводить на экран уведомление об ошибке, но при этом не вываливать на всеобщее обозрение потенциально чувствительную информацию. Вроде имени БД или пути до файла с шаблоном.

try { } catch - вообще не использую, не вижу смысла. В системном программировании он есть..
Пойми php имеет нормальную встроенную систему ошибок, он сам пишет в файл с указанием конкретной строчки кода в файле, от куда произошла ошибка.. В местах где сам обрабатываешь пишешь просто error_log('Произошла ошибка такая-то, вот запрос вызвавший ошибку..'); Под твою задачу остаётся только поставить робота который будет периодически находить error_log в папках на сервере и отсылать письмо счастья, дальше включай воображение - можно целиком отослать, можно обработать как тебе удобней.. По факту отдельную систему обработки ошибок обычно не делают (редко встречается). И это лишняя нагрузка на сервер.. Проще код нормально написать без ошибок.. Стоит опасаться ошибок не в коде, а в логике программ, они куда серьёзнее и не регистрируются как ошибки..

Мануал почитай внимательно, функций обработки ошибок несколько, выбирай исходя из своих задумок.. В повседневной жизни использую наверное <5% от возможностей php и это даёт мне возможность решать 100% задач, в дебри типа перебинживания ошибок вообще не лезу..

Так и не понял в чем проблема, но только что система заработала так, как я этого добивался уже несколько дней...

Алиса(Алиса_в_стране_чудес) писал(а):Все становится чудесатее и чудесатее...

Последние действия:
1. Вынес обработку исключения в индексный файл
2. Перезагрузил страницу - Работает
3. вернул обработку на СТАРОЕ место
4. Перезагрузил страницу - РАБОТАЕТ!

осталось только понять в чем была ситуевина...