Меню
Что нового?

А надо ли проверять модули перед формированием страницы?

GoryachkoRA

GoryachkoRA

Новичок
Привет,

Впервые пишу код PHP. Если пишу программы (win) - всегда делаю проверку на стадии загрузки и цепляю свой Err модуль, формирующий лог, чтобы если программа вылетает - хотя бы иметь понимание - "из-за чего?"

Написал функции для проверки соединения с сервером MySql, проверки наличия на нем базы данных и проверки наличия в базе таблицы. Успех или облом - всё пишется в лог. Хотел дописать функцию проверики прав на базу данных и еще кое-какие возможности и разрешения. Только потом, если все условия true - грузить главную страницу. В противном случае выдать error_page и {совершить какие-то действия, отправить лог админу, написать в хостинг}.

Друг практикует PHP. Сказал буквально "а, нафига?..Развернул базу, залил файлы - все работает. Ну, грохнется хостинг, свернут базу, вирус повредит - твои какие заботы? Пусть backup решит эти проблемы..."

Вопрос: я действительно занимаюсь х..? (Хочу мнение выслушать, стороннее.)
 
GoryachkoRA написал(а):
инения с сервером MySql, проверки наличия на нем базы данных и проверки наличия в базе таблицы. Успех или облом - всё пишется в лог. Хотел дописать функцию проверики прав на базу данных
Нажмите для раскрытия...
Проверка на права к базе прекрасно реализуется средствами самой базы.
То, что ты хочешь сделать, правильные и хорошие желания, но реализуются обычно через исключения, set_error_hanlder(), set_exception_handler(), средства самого php, и т.п. в этом духе.
С другой стороны, пхп достаточно узкоспециализирован, и ведение ошибок в лог, и.т.п. уже реализованы на уровне самого интерпретатора, и являются более предпочтительными способами.
Надо еще помнить о том, что ошибка — друг разработчка и враг продакшна, поэтому поведение в этих разных окружении у ошибок должно быть разным.

А в целом, такие знания приходят только с опытом, а опыт редко бывает бесполезным — поэтому делай, что считаешь нужным, и время само все расставит по местам.
 
  • Like
Реакции: AmdY
Хм..
флоппик написал(а):
реализуются обычно через исключения, set_error_hanlder(), set_exception_handler(), средства самого php, и т.п. в этом духе.
Нажмите для раскрытия...
и
флоппик написал(а):
С другой стороны, пхп достаточно узкоспециализирован, и ведение ошибок в лог, и.т.п. уже реализованы на уровне самого интерпретатора, и являются более предпочтительными способами.
Нажмите для раскрытия...
не одно и то же в широком смысле? Или речь идет об анализе логов, формирующихся интерпретатором (настройки E~ALL, E~NOTICE и т.д.)? Не попадаю ли я тем самым в зависимость от настройки сервера на хосте?

Но генеральную нить мысли, флоппик, я уловил. Спасибо.

P.S. про "...враг продакшна.." намёк в область безопасности?
 
GoryachkoRA написал(а):
Не попадаю ли я тем самым в зависимость от настройки сервера на хосте?
Нажмите для раскрытия...
А кто сказал, что это плохо?
Поведение меняется соотвественно настройке — это правильно и ожидаемо. Если твой софт игнорирует/перекрывает стандартизированные настройки, чье поведение документированно и известно большинству — это плохо.

GoryachkoRA написал(а):
P.S. про "...враг продакшна.." намёк в область безопасности?
Нажмите для раскрытия...
Да. Сообщение об ошибке содержат очень много важной информации для понимания ошибки. Тобой... или кем-то другим, кто ее видит.
 
Хорошо, я понял.
Спасибо, флоппик. Но, возможно, будут еще мнения. Это даст возможность взглянуть на ситуацию под разными углами.

В общем-то нет задачи писать такой код, который бы оказал еще и посильную помощь администрации хостинга (допустим, на основе обработаных ошибок выводил сообщения вроде 'извините, сайт не доступен, ибо сервер поражен вирусом и файлы базы данных были повреждены. Админ, проснись, к тебе пристроились').
Правда, и в этом случае есть свои плюсы.
Но не зря же есть понятие диспансеризации, как преждевременного выявления развивающихся недугов. И живут те, кто им не пренебрегает, в среднем дольше лет на 6-7. 9-10% в общем. От сознательной жизни еще больше :) Эдакий вопрос нравственности на границе объективности и абсурда.

Я согласен с мнением своего друга - не стоит усложнять. Согласен и с флоппиком, безопасности много не бывает.
 
GoryachkoRA написал(а):
Написал функции для проверки соединения с сервером MySql, проверки наличия на нем базы данных и проверки наличия в базе таблицы. Успех или облом - всё пишется в лог. Хотел дописать функцию проверики прав на базу данных и еще кое-какие возможности и разрешения. Только потом, если все условия true - грузить главную страницу.
Нажмите для раскрытия...
А какой в это смысл? Поясняю, почему я считаю данную задачу в контексте PHP бессмысленной.

Делаем запрос. Допустим у нас прошли все проверки прошли нормально, сделали нужные выборку, нарисовали страницу. Предположим, что у нас нет одной из таблиц, проверка зафейлилась, выборку не сделали, страницу не нарисовали. Если бы не было этой проверки запрос все равно бы зафейлился, страница отрисована не была бы. Есть в приложение своя проверка структур таблиц, нет у нас свой проверки, не важно. Запрос который должен бы вернуть данные для страницы не проходит в любом случае и отрисовать страницу не получиться, только выдать заглушку о проблеме на сервере. Но при этом твоя проверка вносит в значимый запрос (в котором получаем данные для страницы) определенный оверхед, и этот оверхед будет на каждый целевой запрос. Так зачем этот оверхед, если в ходе значимого запроса данные для страницы получены не будут? Зачем привносить сущность, надобности в которой нет, тем паче в самом интерпретаторе есть чем отлавливать ошибки.

Я вижу только одну сферу применения данной проверке. Есть ряд задач где она будет полезна: при (пост|пре)инсталяции, при контроле целостности в случае возникновении ошибки для быстрого выявления проблемного места (т.е. в каждом запросе проверок нет, если если запрос зафейлился, то запускаем код выполняющий проверку и прочие нужные действия).

Особо отмечу, что речь в контексте веб приложения которое на каждый клиентский запрос проводит инициализацию.
 
baev, класс!
alekciy, спасибо. В общем-то из Вашего поста все "сущности" были весьма доходчивы. В конечном счёте, я тоже склонен думать, что любое "утяжеление" конструкции - еще один шанс огрести. Был еще такой аргумент (мой, естественно):
- Что если человек не разбирается в технологиях, но хочет использовать мой шаблон? Лог - хороший инструмент.

Хотя теперь мне понятен весь фатализм подобных помыслов. Вот он, далеко ходить не надо: я - человек, который пока не очень хорошо разбирается в этой технологии. if(!понимания основ)... {ну, а дальше все и так ясно};

Так что, да, флоппик, всё верно именно в той части, что не ради вреда, а пользы для и
"...опыт редко бывает бесполезным"
Нажмите для раскрытия...
Спасибо.
 
Привет,
что-то я не могу адекватно оценить полезность try...catch. В ранних версиях PHP не было механизма исключений, тогда ошибки "ловились" простой проверкой возвращаемых булевых значений или же задавался альтернативный обработчик ошибки.

В чем преимущество механизма исключений? Быстродействие? Закос под объектно ориентированный язык программирования? Или вся прелесть в том, что этот механизм позволяет в случае ошибки подниматься по циклам и не делать лишнюю работу (кто-нибудь может привести реальный пример, когда без try...catch ну просто никуда...?) ?
 
GoryachkoRA
try...catch - это узаконенный goto. с точки зрения архитектуры - это гавно. потому что те кто должен довить экцепшины знает слишком много. но главное - это удобство.

в целом. смысл в try...catch не в том, чтобы поймать ошибку. а чтобы её попытаться исправить.
 
Он должен знать как исправлять все от ошибок файловой системы или сетевого седенения до логики приложения или ввода данных от пользователя. Это ли не повод задуматься в адекватности подобного решения.
 
Обработчик знает столько, сколько вы его заставляете знать. Exception'ы лишь направлены на устранение избыточности, которую создают постоянные проверки if'ами, и не более.
 
что-то я не могу адекватно оценить полезность try...catch.
Нажмите для раскрытия...
Вот тебе прототип функции на джаве:

PHP: 
    public EntryUser info(String token, String userName)
            throws MalformedResponseException, IOException, AccessDeniedException, IncorrectTargetException {
Как видишь, это не только классические ошибки(из субд, файлов или сокетов), но и исключительные ситуации в логике(AccessDeniedException, IncorrectTargetException).

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