Mayday, Mayday, Mayday — PHP идет вниз

Эти ошибки включают в себя:

E_ERROR

Фатальные ошибки времени выполнения. Они указывают на ошибки, которые не могут быть восстановлены, такие как проблема выделения памяти. Выполнение скрипта остановлено

E_PARSE

Ошибки синтаксического анализа во время компиляции. Ошибки разбора должны генерироваться только парсером

E_CORE_ERROR

Неустранимые ошибки, возникающие при первоначальном запуске PHP. Это похоже на E_ERROR, за исключением того, что оно генерируется ядром PHP

E_COMPILE_ERROR

Фатальные ошибки времени компиляции. Это похоже на E_ERROR, за исключением того, что оно генерируется Zend Scripting Engine.

Используя комбинацию функции выключения , error_get_last и буферизации вывода , можно создать структуру, которая позволит вам перехватывать фатальные ошибки. Теория работы довольно проста:

1. Зарегистрируйте функцию отключения.
2. Когда вызывается функция завершения работы, проверьте, завершил ли сценарий выполнение должным образом, запросив error_get_last на наличие фатальных ошибок.
3. Обработайте фатальную ошибку, как считаете нужным.

Давайте посмотрим на некоторый код:

<?php
 
ob_start();
 
$res = register_shutdown_function('shutdown');
 
function shutdown()
{
    if ($error = error_get_last()) {
        if (isset($error['type']) && ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR)) {
            ob_end_clean();
 
            if (!headers_sent()) {
                header('HTTP/1.1 500 Internal Server Error');
            }
 
            echo '<h1>Bad Stuff Happend</h1>';
            echo '<p>But that is okay</p>';
            echo '<code>' . print_r($error, true) . '</code>';
        }
    }
}
 
ob_end_flush();
?>

Вся сгенерированная страница перед отправкой клиенту помещается в выходной буфер. Использование здесь буферизации вывода позволяет нам избавиться от частично сгенерированного контента при возникновении фатальной ошибки и заменить его пользовательским сообщением об ошибке. Например:

<?php
 
ob_start();
 
$res = register_shutdown_function('shutdown');
 
function shutdown()
{
    if ($error = error_get_last()) {
        if (isset($error['type']) && ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR)) {
            ob_end_clean();
 
            if (!headers_sent()) {
                header('HTTP/1.1 500 Internal Server Error');
            }
 
            echo '<h1>Bad Stuff Happend</h1>';
            echo '<p>But that is okay</p>';
            echo '<code>' . print_r($error, true) . '</code>';
        }
    }
}
 
?>
 
<h1>My Bad Day</h1>
 
<?php require 'FileNotFound.php'; ?>
 
<p>What a bad day...</p>
 
<?php
 
ob_end_flush();
 
?>

Неудачный вызов require генерирует фатальный E_COMPILE_ERROR. Мы улавливаем ошибку, и вместо того, чтобы рассказывать клиенту о «моем плохом дне», мы убираем это и даем пользователю очень утешительное сообщение, что все в порядке, даже если наш сайт взорвался. Вместо того, чтобы делать что-то умное, например регистрировать ошибку, мы отображаем ее

<h1>Bad Stuff Happend</h1><p>But that is okay</p><code>Array
(
    [type] => 64
    [message] => require() [<a href="function.require">function.require</a>]: Failed opening required 'FileNotFound.php' (include_path='.:/usr/local/lib/php')
    [file] => /home/michael/www/eggplant/public_html/samples/fatal/index.php
    [line] => 28
)
</code>

Если мы исправим отсутствующий необходимый файл, добавив следующий скрипт:

<?php
i'm an idiot
?>

… Мы можем отловить фатальную ошибку E_PARSE в нашем обработчике завершения работы:

<h1>Bad Stuff Happend</h1><p>But that is okay</p><code>Array
(
    [type] => 4
    [message] => syntax error, unexpected T_STRING
    [file] => /home/michael/www/eggplant/public_html/samples/fatal/FileWithParseError.php
    [line] => 2
)
</code>

Давайте исправим этот необходимый файл с помощью реального кода:

<?php
 
myBadTypo();
 
function myBadDay()
{
    ini_set('memory_limit', '5000');
 
    echo str_repeat('bad bad bad', 50000);
}
 
?>

… Другой поймал E_ERROR:

<h1>Bad Stuff Happend</h1><p>But that is okay</p><code>Array
(
    [type] => 1
    [message] => Call to undefined function myBadTypo()
    [file] => /home/michael/www/eggplant/public_html/samples/fatal/FileThatBlowsMemLimits.php
    [line] => 3
)
</code>

Наконец, допустим, мы отсортировали необходимый файл, но взорвали банк с доступной памятью:

<?php
 
myBadDay();
 
function myBadDay()
{
    ini_set('memory_limit', '5000');
 
    echo str_repeat('bad bad bad', 50000);
}
 
?>

… мы можем перехватить фатальную ошибку E_ERROR и в нашем обработчике завершения работы:

<h1>Bad Stuff Happend</h1><p>But that is okay</p><code>Array
(
    [type] => 1
    [message] => Allowed memory size of 262144 bytes exhausted (tried to allocate 550001 bytes)
    [file] => /home/michael/www/eggplant/public_html/samples/fatal/FileThatBlowsMemLimits.php
    [line] => 9
)
</code>

That’s all pretty good, however there are some limits that need to be taken into consideration:

• E_PARSE errors on the include that builds out the shutdown structure will not be caught, as the interpreter can’t get beyond the parse error to put it into place.
• E_CORE_ERROR errors? These are environmental errors caught when PHP itself is bootstrapping — pre-script interpretation. No dice.
• When using output buffering in combination with the ob_gzhandler, take care when cleaning the buffer. Chances are the Content-Encoding: gzip header was already set and you will need to follow suit.
• If your output buffer has already been flushed before hitting a fatal error and the shutdown function, your content to that point is already gone. Check ob_get_status to see if that is the case.

For an similar implementation using a shutdown function, check out eZ Components’ Execution class.