1.0Чудо{вищные} заметкиhttps://miracle.rpz.nameMiRacLehttps://miracle.rpz.name/author/miracle/<h4>Повесть об <a href="http://php.rinet.ru/manual/ru/language.operators.errorcontrol.php">операторе управления ошибками</a></h4> <strong>Предисловие.</strong> А началось всё с того, что надо "переносить" множество сайтов с одного сервера на другой. По такому случаю решил-таки установить на новом сервере php5.1(раньше это делать боялся - несколько сотен проектов - и все проверить на работоспособность после апгрейда <strike>нет возможности</strike> долгая и нудная операция). Так собственно и сделал - по мере переноса сайтов, проверяю что и как работает и при необходимости либо настраиваю php_flag-ами нужные переменные для обратной совместимости, либо правлю проблемный код вручную. <strong>Часть первая</strong> Ошибки и warning-и возникали в основном из-за <a href="http://php.rinet.ru/manual/ru/ini.core.php#ini.register-long-arrays">register_long_arrays</a> Off и присвоения неинициализированным переменным. Потихоньку исправляю. И вот сегодня при переносе очередного сайта обнаружил, что на новом сервере он отказался функционировать должным образом. Ну и ладно... <a href="http://php.rinet.ru/manual/ru/ini.core.php#ini.error-reporting">error_reporting</a> E_ALL, <a href="http://php.rinet.ru/manual/ru/ini.core.php#ini.display-errors">display_errors</a> On... - <strike>нет</strike> не видно ошибок. Нет их в логах php, нет в логах apache и в браузере их тоже нет... тысяча чертей... <strong>Часть вторая</strong>. Пошли дальше - открываю index.php и начинаю var_dump-ить переменные. Методом научного тыка нашёл проблемный файл. Методом всё того же тыка(который научный) вычислил, что проблемы создаёт adodb. Полез в его дебри... <blockquote>К слову сказать - описываемый сайт сделан не мной (и не моими коллегами), посему разбираться что именно не работает и кто "накосячил" удовольствие приносило сомнительное. Движок какой-то ***nuke, повсюда коментарии в стиле "holy hack","fix me" и т.д. - т.е. взять и тупо обновиться до current-версии движка трудновато - приходиться делать всё по-дедовски...</blockquote> И так я в дебрях adodb. Задумал его обновить, но заметив коментарий в коде "patched for ***nuke version x.y.z" передумал. Стал "дебажить" вручную. Красота кода поражает своей безалаберностью ;o) - сразу вспоминается старый добрый мультфильм о Простоквашино и письме, которое писал Дядя Фёдор... После 10-ти минутного поиска, я-таки нашёл причину отсутствия ошибок в логах. <strong>Часть третья</strong>. Причиной служила собака. Не овчарка, не бульдог. А аттавизм, доставшийся современному php от первых его версий оператор "@". Adodb подгружала драйвер для типа СУБД следующим образом: @include '/path/to/driver_'.$type.'.php'; Тут надо брызгать слюнями и сыпать проклятия в адрес разработчиков adodb и обещания вступить в сексуальную связь с их родственниками.... Но я этого делать не буду... PHP сделал ровно то, о чём его просили - подавил ошибку, которая возникла при include файла. Но на этом не остановился... подавил все ошибки(в том числе и фатальные, которые случились после выполнения кода в Include). Ошибку в итоге нашёл и исправил (два раза декларировалось одно и тоже свойство в объекте), а вот про собак больше молчать не могу - много раз уже обсуждалась их полезность и бесполезность, много доводов и выводов из этих обсуждений выносилось в факи и книги... А я отныне считаю, что они должны быть низвергнуты! Ибо невинная болонка, сиротливо охраняющая операцию типа @fopen('not_existen.file','r') может попортить мегабайт невостановимых нервных клеток и увеличить время отладки до вечности. <strong>Эпилог.</strong> Всех соб@к на <strike>хозяйственное</strike> электронное мыло. Там им почёт и слава... а в коде (php-коде) им больше места нет! Да будет так. Алюминий. Technorati Tags: <a rel="tag" href="http://technorati.com/tag/dailyWTF">dailyWTF</a>, <a rel="tag" href="http://technorati.com/tag/dev">dev</a>, <a rel="tag" href="http://technorati.com/tag/php">php</a>rich