Изучаю PHP. Интересует мнение гуру про код.

[Gas]

HraKK
так, ходить вокруг да около это не дело.
"(просто удобней)" - это касалось display_errors=on на dev'е, на продакшене off - без вариантов, log_errors=on - на продакшене полюбому, на dev'е в зависимости от display_errors или других сексуальных предпочтений разработчика.

dimagolov
ok, твоё мнение понятно и _более чем_ имеет право на существование, у меня на dev on (не на qa), при включенных логах, тоже не вижу в этом ничего плохого.

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

 

[dimagolov]

мои аргументы исходят из особенности моей работы - у меня много JS и сложный многофреймовый дизайн, так что отображение php ошибок приводит или к нарушению синтаксиса JS и полной нефункциональности, при этом никакого текста ошибок не видно все равно, или в большинстве случаев они все равно не видны в скрытых элементах html.
если динамического контента не много, то может оно и имеет смысл, но я при отладке просто смотрю в таком порядке:
0. ошибки синтаксиса php ловятся еще кодированием ZendGuard
1. ошибки JS идут в JS debugger
2. если что-то работает не так - смортятся как кастомные логи (которых тоже много, почти десяток на разные аспекты) так и лог ошибок скрипта
3. PHP Fatal error если такие вдруг (крайне редко вообще-то при таком подходе) возникают смотряться в глобальном логе.

 

[Gas]

много JS

аргументы обоснованные, но иногда неработающий js позволяет быстрее выловить как-нить notice.
В целом, это специфика проекта и вариант "как удобнее" работает, особенно когда пятница 13

 

[Mr_Max]

Shock13666
Сам как думаешь?

-~{}~ 13.06.08 21:29:

Ребята, извините, пожалуйста, за вмешательство в Ваш спор.
Но какое отношение он имеет к первоначальном контексте вопроса ТС-а?

 

[Shock13666]

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

 

[berkut]

не, ну оч удобно смотреть в 10!! логов. чё так мало? ещё можно на некоторые аспекты сливать не в лог, а на емаил. гулять так гулять

 

[Gas]

Но какое отношение он имеет к первоначальном контексте вопроса ТС-а?

Ну вообще-то никакого, как и многие споры на форуме.

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

berkut
ну случаи разные бывают, лог ошибок, performance log, логи каких-то специфических операций: платежи, "хитрый" поиск и т.д.

 

[dimagolov]

berkut, ну Gas ответил в общем и попал правильно, но скажу подробно. есть еще такой нюанс, что в конфиге у меня можно отключать отдельные логи или виды записываемой туда инфы
1. ErrorLog.log - notice, warning, catchable fatal
2. Query.log - логируются запросы к back-end, базе и их время исполнения
3. SqlError.log - ну тут понятно
4. fakeget.log - это если параметры запроса на каком-то этапе были признаны некоррктными, обычно это ошибки составления запросов, кулхацкеров еще не наблюдал
5. Login.log - все что связано с авторизацией в системе.
6. MailLog.log - аспекты с генерацией сообщений в почту
7. FileDownload.log - запросы на загрузку файлов
8. Session.log - аспекты связанные с сессиями, если содержимое сессии не соответствует ожидаемому (то есть ошибки обработки сессий на клиенте или кулхацкеры) + есть несколько специфических нюансов, за которыми хочется следить отдельно
9. CommonLog.log куда пишется все остальное что хочется увидеть для отладки back-end а

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

 

[berkut]

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

врядли тут можно говорить о перформанс лог и проч. и относительного остального - чем хуже скидывать их в 1 лог? и уж тем-более на деве?

 

[HraKK]

еще мысли будут?

 

[dimagolov]

чем хуже скидывать их в 1 лог? и уж тем-более на деве?

[offtopic]
- Армяне лучше, чем Грузины!!
- Чем лучше?
- Чем Грузины!
[/offtopic]
мне удобно тем, что так я выделил специфические аспекты, которые меня волнуют в отрыве от всей остальной отладочной инфы, и сразу вижу по дате обновления лога, когда эти аспекты последний раз возникали, а не пересматриваю общий лог.
....
может у кого-то ошибки пишуться в общий лог с кодами по которым потом оно автоматом парситься в некую систему просмотра и статистики, тогда ему будет ничем не хуже, а может и лучше складывать в один лог.

 

[Фанат]

dimagolov, если внимательно прочитать по ссылке, то там все написано. и это, и многое другое

-~{}~ 14.06.08 12:40:

Shock13666
ну так если скрипт не падает у тебя каждые две минуты, то при чем здесь http://phpfaq.ru/debug?
Там написано, как найти ошибку. Если она есть. Если же у тебя ошибок нету, то при чем здесь вообще эта ссылка?

 

[Shock13666]

На будущее, чтобы если появится ошибка - сразу ее видеть. Но все равно спс.
Можно еще прокоментить по пунктам, указаным в первом посте?

 

[Фанат]

Shock13666
ты сайт для себя делаешь? будешь его единственным посетителем? тогда да, действительно. если появится ошибка, то ты сразу её увидишь. логично

 

[Shock13666]

Да. Я буду единственным его посетителем. На данный момент планы у меня такие.

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

Кстати, функция, которая берет значения из базы данных, например get_links(). Она правильно написана, или лучше было бы иначе?

 

[Фанат]

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

Ну, если по мелочи придираться, то global и проверка на $number - лишние.

 

[ohppc]

Автор оригинала: dimagolov
2 all:
может стоит в http://phpfaq.ru/debug

ini_set('display_errors',1);
error_reporting(E_ALL);

поменять на

error_reporting(E_ALL);
ini_set('display_errors','off');
ini_set('log_errors','on');
ini_set('error_log',<here full path to script error log file>);

или путь лог файла это слишком сложно?

думаю, не каждый нуб сможет нормально указать путь.

 

[Фанат]

можно не указывать - пусть идет в лог ошибок апача.