Повесть об операторе управления ошибками
Предисловие.
А началось всё с того, что надо “переносить” множество сайтов с одного сервера на другой. По такому случаю решил-таки установить на новом сервере php5.1(раньше это делать боялся – несколько сотен проектов – и все проверить на работоспособность после апгрейда нет возможности долгая и нудная операция). Так собственно и сделал – по мере переноса сайтов, проверяю что и как работает и при необходимости либо настраиваю php_flag-ами нужные переменные для обратной совместимости, либо правлю проблемный код вручную.
Часть первая
Ошибки и warning-и возникали в основном из-за register_long_arrays Off и присвоения неинициализированным переменным. Потихоньку исправляю. И вот сегодня при переносе очередного сайта обнаружил, что на новом сервере он отказался функционировать должным образом. Ну и ладно… error_reporting E_ALL, display_errors On… – нет не видно ошибок. Нет их в логах php, нет в логах apache и в браузере их тоже нет… тысяча чертей…
Часть вторая.
Пошли дальше – открываю index.php и начинаю var_dump-ить переменные. Методом научного тыка нашёл проблемный файл. Методом всё того же тыка(который научный) вычислил, что проблемы создаёт adodb. Полез в его дебри…
К слову сказать – описываемый сайт сделан не мной (и не моими коллегами), посему разбираться что именно не работает и кто “накосячил” удовольствие приносило сомнительное. Движок какой-то ***nuke, повсюда коментарии в стиле “holy hack”,”fix me” и т.д. – т.е. взять и тупо обновиться до current-версии движка трудновато – приходиться делать всё по-дедовски…
И так я в дебрях adodb. Задумал его обновить, но заметив коментарий в коде “patched for ***nuke version x.y.z” передумал. Стал “дебажить” вручную. Красота кода поражает своей безалаберностью ;o) – сразу вспоминается старый добрый мультфильм о Простоквашино и письме, которое писал Дядя Фёдор…
После 10-ти минутного поиска, я-таки нашёл причину отсутствия ошибок в логах.
Часть третья.
Причиной служила собака. Не овчарка, не бульдог. А аттавизм, доставшийся современному php от первых его версий оператор “@”. Adodb подгружала драйвер для типа СУБД следующим образом: @include ‘/path/to/driver_’.$type.’.php’;
Тут надо брызгать слюнями и сыпать проклятия в адрес разработчиков adodb и обещания вступить в сексуальную связь с их родственниками…. Но я этого делать не буду…
PHP сделал ровно то, о чём его просили – подавил ошибку, которая возникла при include файла. Но на этом не остановился… подавил все ошибки(в том числе и фатальные, которые случились после выполнения кода в Include).
Ошибку в итоге нашёл и исправил (два раза декларировалось одно и тоже свойство в объекте), а вот про собак больше молчать не могу – много раз уже обсуждалась их полезность и бесполезность, много доводов и выводов из этих обсуждений выносилось в факи и книги… А я отныне считаю, что они должны быть низвергнуты! Ибо невинная болонка, сиротливо охраняющая операцию типа @fopen(‘not_existen.file’,’r’) может попортить мегабайт невостановимых нервных клеток и увеличить время отладки до вечности.
Эпилог.
Всех соб@к на хозяйственное электронное мыло. Там им почёт и слава… а в коде (php-коде) им больше места нет! Да будет так. Алюминий.
Technorati Tags: dailyWTF, dev, php
Эх. Писали бы модульные тесты, не было бы проблем.
Кстати, я каюсь, так как использую собаку для принудительного вывода.
@flush(); ob_flush();
Гадкий сервер иногда выдаёт ошибку, что нечего флашить. Очень достаёт на development-серверах.
Какие модульные тесты, окститесь… Я выступал в роли представителя хостинговой компании. По собственной инициативе переводил подопечные сервера на php5 – какие тут могут быть тесты? на чужие-то проекты…
А по поводу “иногда использую” – я тоже использую при работе с mssql – ибо иных способов “изловить” возникающие ошибки не пока не получается.