Локализация ошибок на production

После запуска проектов на продакшн, debug режим, целесообразно отключить установив константу DEBUG в false в файле первичной конфигурации. А в админ разделе включить логирование ошибок на production $sky->s_prod_error=1. При этом трассировка будет отключена, но ошибки будут логироваться в memory.id=4. Смысл в том, что на продакшн ошибок не должно быть в этой ячейке. Если они там появляются - необходимо исправлять код проекта, так, чтобы ошибок не было. После возможно нескольких иттераций, когда ошибки не будут регистрироваться в течение длительного времени, можно установить $sky->s_prod_error=0, отключить регистрацию ошибок, при этом coresky код станет работать немного быстрее.

Для кода крышевания, рекомендуется использовать синоноим инструкции exit - die. Прекращение работы скрипта, после ее выполнения, не регистрируется как ошибка, и информация не попадает в memory.id=4, когда включено логирование ошибок на продакшн. Если нужно чтобы ошибка регистрировалась - используйте throw new Error('описание ошибки').

При прекращении работы скрипта для обычных, не ajax запросов, по инструкциям die или exit (если не приняты специальные меры), или при использовании throw new Error, показывается одна и та же страница "Ошибка 404". В режиме "debug", дополнительно показывается трассировка.

Специальные меры таковы: если перед "exit;" написать: $sky->tailed = true; в STDOUT ничего дополнительно передаваться не будет (страница "Ошибка 404" не будет показана) в callback функции для register_shutdown_function(), которая вызывается в конструкторе объекта SKY.

Наверное, многим привычнее пользоваться PHP функционалом "log_errors", но так как разница в производительности кода coresky небольшая (когда отключено или включено $sky->s_prod_error), настоятельно рекомендуется пользоваться memory.id=4. К тому же, в "log_errors" могут регистрироваться только ошибки PHP, но coresky код генерирует еще много разных ошибок. Функция user_error(), к сожалению не дает возможности передавать глубину трассировки, чтобы верно отображать место ошибки с помощью debug_backtrace(), т.е. не юзабельна. Да, можно было бы передавать глубину трассировки не напрямую через нее в "error handler" класса SKY. но, код coresky, проектируется так, чтобы минимально(!) зависеть от внешних настроек и данных. Разработчику удобно, все необходимое для работы с проектом, иметь в одном месте - на главной странице админ. раздела.

Если вы первый раз используете coresky, для пущей уверенности, можно включить одновременно и ini_set('log_errors', true); и $sky->s_prod_error=1 (устанавливается на главной странице админ. раздела, пользователем "root").

В Интернете существует масса ботов (и не только), которые посылают множество запросов на веб-сайты, которые не могут возникать при нормальном использовании сайтов. Это делается хакерами с целью поиска уязвимости на сайтах. В SKY-приложениях следует использовать код "крышевания" для таких запросов и прерывать выполнение работы скрипта по инструкции die как можно раньше. Не имеет смысла обслуживать такие запросы, затрачивая ресурсы сервера. Кстати, "крышевание" отличается от валидации данных, лишь в том, что последнее подразумевает не агрессивное намерение запроса и должно быть обработано по другому.

В связи с этим, в coresky коде, имеется класс ошибок, - так называемые "errors on debug only". При поступлении запросов, описанных выше, на production инсталляцию веб-приложения, работающего не в debug режиме, скрипт прекращает выполнение по инструкции die и не регистрирует ошибку. Таких запросов слишком много на продакшн и если их все регистрировать как ошибки, это будет сильно мешать находить реальные ошибки программиста. При development инсталляции, режим debug включен. Ввиду того, что подразумевается, что попытки взлома исключены для сайта, который не доступен из Интернет, такие внезапные прерывания выполнения скрипта по инструкциям exit или die, регистрируются как ошибки, так как могут, все таки быть следствием ошибки программирования, которую требуется устранить.

Например, представьте что имеется запрос:

001 002

<? $row = sql('>select * from article where id=$.', $_GET['id']);

Логика приложения, подразумевает, что $_GET['id'] должен иметь только лишь числовое значение. Если значение другое, скрипт прекращает свое выполнение. Здесь код "крышевания" заключен в самой логике шаблона $. В следующем примере:

001 002 003

<? preg_match("/^\w+$/", $_GET['uri']) or die; $row = sql('>select * from article where uri=$+', $_GET['uri']);

Код "крышевания" написан программистом. Таким образом, выполнение инструкций die и ее синонима exit, по умолчанию, вызывает ошибку типа "errors on debug only"