Действительно ли исключения PHP более полезны, чем ошибки? (ADV)

Question

Я считаю, что в правильно закодированных системах ошибки (как ошибки или исключения) не должны быть возможными (за исключением того, что сервер БД / memcached выходит из строя, вызывая сбой запроса). Наш код не должен опираться на какие-либо предположения для правильной работы и должен быть как можно более пуленепробиваемым.

Однако, чтобы наши системы справлялись с проблемами наиболее удобным для пользователя способом, мы должны создать и внедрить какую-то «ловящую систему», чтобы гарантировать, что, если что-нибудь пойдет не так, как для нашего сервера, так и для персонала. о конечном пользователе позаботятся.

С этой целью PHP предлагает два решения - ошибки и исключения. Ошибки состоят из 5 значений, а исключения состоят из 5 значений, заключенных в объект. Оба позволяют возвращать данные, которые неоценимы во время сборки приложения.

5 значений: $ error_code, $ error_message, $ file, $ line, $ context

Обычно, в нашем стремлении к правильному программированию ООП, выбор по умолчанию всегда состоит в том, чтобы преследовать объекты - но в таком случае я не уверен, насколько они полезны на самом деле. При использовании исключений дополнительная память тратится впустую из-за необходимости переноса значений в объект (для этого часто требуются дополнительные файлы, содержащие классы исключений). Более того, вы должны заключить любой код, который, по вашему мнению, может не работать, в блок TRY / CATCH {}. Это оставляет метод обработки ошибок открытым для человеческой ошибки, поскольку точки отказа могут не покрываться разработчиком. Чтобы обезопасить себя от этого, вы можете использовать set_exception_handler, которому будут переданы любые исключения, которые не были перехвачены. Плохая вещь в обработчике исключений состоит в том, что выполнение будет остановлено после вызова обработчика exception_handler - поэтому не существует такого понятия, как восстанавливаемое / игнорируемое исключение, если оно не будет перехвачено в блоке try / catch.

С другой стороны, ошибки всегда глобальны и могут быть обработаны любой функцией / классом, установленным set_error_handler. Это устраняет необходимость в дополнительных классах исключений, объектной памяти или строках кода try / catch. Как и исключения, ошибки также поставляются со встроенными кодами ошибок, которые (в отличие от исключений) можно использовать для продолжения выполнения сценария для незначительных или неважных проблем сценария. Кроме того, большинство функций PHP вызывает ошибки, поэтому вы не будете идти против течения языка.

Итак, учитывая, что вы все равно должны поддерживать обработку ошибок (делать с языком PHP), какова цель напрасной траты дополнительного кода и памяти, а также реализации исключений? Мы просто слепо делаем это, потому что это ошибка в форме объекта или в дизайне приложения есть реальная выгода, что обычные ошибки нам не позволяют?

Answer 1

Я перестал читать после этой строки:

Я верю, что в правильной кодировке системы - ошибки (как ошибки или исключения) не должно быть возможным (за исключением БД / memcached сервер падает, вызывая запрос сбой).

Это целая цель исключений - как конструкция для управления исключительными обстоятельствами в коде.

Если вы генерируете исключения как часть un исключительного обычного потока программы, вы делаете что-то не так.

Если вы не знаете, почему исключения полезны для исключительных обстоятельств, то, возможно, вам нужно потратить некоторое время на настоящий язык ОО. (Подсказка: PHP не является настоящим ОО-языком.)

Answer 2

Я полагаю, что существует философское различие между определениями ошибок и исключений .

Ошибка - это запрограммированный недостаток, сгенерированный логической ошибкой в ​​коде. Передача strlen () неверного количества аргументов, естественно, должна быть ошибкой. Исключение , с другой стороны, обрабатывает те случаи, когда все запрограммировано правильно, но ваш код взаимодействует с ресурсами вне базы кода (файловая система, веб-служба, внешний исполняемый файл и т. Д.). Хотя ожидается, что такие внешние ресурсы должны отлично работать при каждом вызове, будут случаи, выходящие за рамки контроля вашей программы, которые не относятся к сбоям вашего кода (файловая система отключается, время ожидания соединения и т. Д.) , Поскольку эти проблемы связаны с внешними факторами, они считаются исключениями.

Основное отличие состоит в том, что ошибка возникает в собственном коде, тогда как исключение возникает в случае аномалии, обнаруженной в стороннем ресурсе.

Answer 3

Наряду с объектно-ориентированным подходом ко всем этим ошибкам приходят большие преимущества расширения исключений.

Таким образом, вы можете перехватывать все под-исключения, скажем, IOException в одном блоке перехвата (FileNotFoundException, FileNotWritableException, ...), и все другие исключения в другом, где вы можете снова вызвать это исключение: 1003 *

try
{
    // [...] (some code causing the exception)
}
catch(IOException $e)
{
    // do your processing here, like let's say set correct filemodes.
}
catch(Exception $e)
{
    // catches all other exceptions
}

Также они предлагают вам более стандартизированный способ обработки ошибок в ваших сценариях. Когда вы используете блоки try / catch, обработка ошибок почти всегда будет выглядеть одинаково и во многих случаях более понятна, чем обычные ошибки с кодами и т. Д.

Что вы можете понять лучше:?

switch($errorCode)
{
    case 1450:
        // Create the database column
        break;
}

// or

catch(ColumnNotFoundException $e)
{
    // Create the database column
}

Answer 4

Функция fopen () имеет возможность вернуть следующее:

Если не удается открыть, ошибка уровня E_WARNING генерируется. Вы можете использовать @ подавить это предупреждение.

Вы можете использовать оператор подавления, но он порождает изрядное количество накладных расходов. Блоки try / catch позволяют вам одновременно регистрировать эту ошибку, продолжать обычное выполнение, отображать пользовательские ошибки для своих пользователей и регистрировать ошибку одним махом. Для меня нет ничего проще в том, что касается преимуществ использования обработки исключений в моих документах.

Кроме того, если вы используете какой-либо компонент Zend Framework (включая любой из классов API Google), от вас ожидают, что вы будете обрабатывать исключения самостоятельно, так как они происходят и будут происходить.