В PHP5 я должен использовать Исключения или trigger_error/set_error_handler? [закрытый]

Это зависит от ситуации. Я склонен использовать Исключения, когда я пишу бизнес-логику / внутренности приложения и trigger_error для Блока проверки допустимости и вещи того вида.

pro's использования Исключений на логическом уровне должен позволить Вашему приложению делать в случае такой ошибки. Вы позволяете приложение, выбрал вместо того, чтобы иметь бизнес-логику, знают, как представить ошибку.

pro's использования trigger_error для Блока проверки допустимости и вещи той природы, скажем,

try {
    $user->login();
}  catch (AuthenticationFailureException $e) {
    set_error_handler("my_login_form_handler");
    trigger_error("User could not be logged in. Please check username and password and try again!");
} catch (PersistenceException $pe) { // database unavailable
    set_error_handler("my_login_form_handler"); 
    trigger_error("Internal system error. Please contact the administrator.");
}

, куда my_login_form_handler красивые вещи строка и помещают элемент в видимую область выше формы входа в систему.

Очевидно, нет никакого "Одного Правильного Пути", но существует множество мнений об этом. ;)

Лично я использую trigger_error для вещей, которые исключения не могут сделать, а именно, уведомления и предупреждения (т.е. материал Вы хотите быть зарегистрированными, но не остановить поток приложения таким же образом, что ошибки/исключения делают (даже при ловле их на некотором уровне)).

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

, Таким образом, мое эмпирическое правило - это:

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

причина того, чтобы выдать исключения в последнем случае (в противоположность инициированию ошибок), то, что исключения намного более выразительны, учитывая, что Вы используете правильно названные подклассы Исключения. Я нахожу, что использование исключений Стандартной Библиотеки PHP является хорошей начальной точкой при решении что исключения использовать: http://www.php.net/~helly/php/ext/spl/classException.html

Вы могли бы хотеть расширить их для получения более семантически корректных исключений для особого случая, как бы то ни было.

Я люблю идею использовать исключения, но мне часто вовлекали сторонние библиотеки, и затем если они не используют исключения, Вы заканчиваете с 3-4 разными подходами к проблеме! Пехлеви использует исключения. CakePHP использует пользовательский обработчик ошибок, и большинство библиотек PEAR использует ГРУШУ:: Ошибочный объект.

я, который БЫЛ один истинный путь в этом отношении. Пользовательский маршрут обработчиков ошибок является, вероятно, самым гибким в этой ситуации. Исключениями является прекрасная идея хотя, если Вы или только используете свой собственный код или пользуетесь библиотеками, которые используют их.

, К сожалению, в мире PHP мы все еще страдаем от отказа умереть от PHP4, таким образом, вещи как исключения, в то время как они могут представить наиболее успешную практику, невероятно не спешили завоевывать популярность, в то время как все все еще пишут вещи смочь работать в и 4 и 5. Надо надеяться, этот разгром теперь заканчивается, хотя к тому времени, когда он делает, у нас будут силы между 6 и 5 вместо этого...

/ меня содержит голову в руках...

Исключениями является современный и устойчивый способ сигнализировать о состоянии ошибки / исключительная ситуация. Используйте их :)

Идея исключения изящна и делает процесс обработки ошибок настолько гладким. но это только применяется, когда у Вас есть соответствующие классы исключений и в разработке команды, еще одной важной вещью являются "стандартные" исключения. таким образом, если бы Вы планируете использовать исключения, Вы лучше сначала стандартизировали бы свои типы исключительной ситуации, или лучший выбор состоит в том, чтобы использовать исключения из некоторой популярной платформы. еще одна вещь, которая относится к PHP (где можно написать код, возражают занимающемуся ориентированием спортсмену, объединенному со структурным кодом), является этим, если Вы пишете свое целое приложение с помощью классов. Если Вы пишете объектно-ориентированный, то исключения лучше наверняка. в конце концов, я думаю, что Ваш процесс обработки ошибок будет намного более гладким за исключением, чем trigger_error и материал.

Необходимо использовать исключения при "Исключительных обстоятельствах", это - при вызове метода doFoo (), необходимо ожидать, что это будет работать, если по некоторым причинам doFoo будет не мочь сделать, это - задание затем, это должно повысить исключение.

Много старого кода php проявило бы подход возвращения false или пустого указателя, когда отказ произошел, но это делает вещи трудно для отладки, исключения делают эту отладку намного легче.

, Например, говорят, что Вы метод назвал getDogFood (), который возвратил массив объектов DogFood, если Вы назвали этот метод, и он возвращает пустой указатель, когда что-то идет не так, как надо, как Ваш код вызова сможет сказать, был ли пустой указатель возвращен, потому что была ошибка или нет только никакого доступного корма для собак?

Относительно контакта с библиотеками унаследованного кода, которые используют встроенную регистрацию ошибок php, можно переопределить регистрацию ошибок с set_error_handler () функция, которую Вы могли использовать, чтобы затем повторно бросить универсальное Исключение.

Теперь, когда у Вас есть весь Ваш код, выдающий подробные исключения, Вы свободны решить, что сделать с ними в некоторых частях Вашего кода, можно хотеть поймать их и попробовать альтернативные методы, или можно зарегистрировать их использующий собственные функции входа, которые могли бы зарегистрироваться к базе данных, файлу, электронной почте - какой бы ни Вы предпочитаете. Короче говоря - Исключения более гибки.

If you want to use exceptions instead of errors for your entire application, you can do it with ErrorException and a custom error handler (see the ErrorException page for a sample error handler). The only downside to this method is that non-fatal errors will still throw exceptions, which are always fatal unless caught. Basically, even an E_NOTICE will halt your entire application if your error_reporting settings do not suppress them.

In my opinion, there are several benefits to using ErrorException:

1. A custom exception handler will let you display nice messages, even for errors, using set_exception_handler.
2. It does not disrupt existing code in any way... trigger_error and other error functions will still work normally.
3. It makes it really hard to ignore stupid coding mistakes that trigger E_NOTICEs and E_WARNINGs.

4. You can use try/catch to wrap code that may generate a PHP error (not just exceptions), which is a nice way to avoid using the @ error suppression hack:

   try {
    $foo = $_GET['foo'];
   } catch (ErrorException $e) {
    $foo = NULL;
   }
   

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