php set exception handler
Исключения
Содержание
Начиная с PHP 8.0.0, ключевое слово throw является выражением и может использоваться в контексте других выражений. В более ранних версиях оно являлось оператором и требовало размещения в отдельной строке.
catch
Начиная с PHP 7.1.0, блок catch может принимать несколько типов исключений с помощью символа ( | ). Это полезно, когда разные исключения из разных иерархий классов обрабатываются одинаково.
Начиная с PHP 8.0.0, задание переменной для пойманного исключения опционально. Если она не задана, блок catch будет исполняться, но не будет иметь доступа к объекту исключения.
finally
Глобальный обработчик исключений
Примечания
Внутренние функции PHP в основном используют сообщения об ошибках, и только новые объектно-ориентированные модули используют исключения. Однако, ошибки можно легко преобразовать в исключения с помощью класса ErrorException. Однако это не сработает для фатальных ошибок.
Пример #3 Преобразование сообщения об ошибках в исключение
Примеры
Пример #4 Выбрасывание исключений
// Продолжение выполнения
echo «Привет, мир\n» ;
?>
Результат выполнения данного примера:
Пример #5 Обработка исключений с помощью блока finally
// Продолжение нормального выполнения
echo «Привет, мир\n» ;
?>
Результат выполнения данного примера:
Пример #6 Взаимодействие между блоками finally и return
Результат выполнения данного примера:
Пример #7 Вложенные исключения
Результат выполнения данного примера:
Пример #8 Обработка нескольких исключений в одном блоке catch
class MyOtherException extends Exception
Результат выполнения данного примера:
Пример #9 Пример блока catch без указания переменной
Допустимо начиная с PHP 8.0.0
class SpecificException extends Exception <>
function test () <
throw new SpecificException ( ‘Ой!’ );
>
try <
test ();
> catch ( SpecificException ) <
print «Было поймано исключение SpecificException, но нам безразлично, что у него внутри.» ;
>
?>
Пример #10 Throw как выражение
Допустимо начиная с PHP 8.0.0
class SpecificException extends Exception <>
function test () <
do_something_risky () or throw new Exception ( ‘Всё сломалось’ );
>
User Contributed Notes 12 notes
If you intend on creating a lot of custom exceptions, you may find this code useful. I’ve created an interface and an abstract exception class that ensures that all parts of the built-in Exception class are preserved in child classes. It also properly pushes all information back to the parent constructor ensuring that nothing is lost. This allows you to quickly create new exceptions on the fly. It also overrides the default __toString method with a more thorough one.
interface IException
<
/* Protected methods inherited from Exception class */
public function getMessage (); // Exception message
public function getCode (); // User-defined Exception code
public function getFile (); // Source filename
public function getLine (); // Source line
public function getTrace (); // An array of the backtrace()
public function getTraceAsString (); // Formated string of trace
class TestException extends CustomException <>
?>
Here’s a test that shows that all information is properly preserved throughout the backtrace.
echo » ;
?>
Here’s a sample output:
Throwable exception и ошибки в php7
Обратите внимание, что другие виды ошибок, такие как warinng и notice остаются без изменения в php 7.
Throwable
Оба класса, и Error и Exception реализуют новый интерфейс Throwable.
Новая иерархия исключения состоит в следующем:
Если Throwable определить в коде PHP 7, то выглядит это так:
Этот интерфейс должен быть знаком. Методы Throwable практически идентичны методам Exception. Разница лишь в том, что Throwable::getPrevious() может вернуть любой экземпляр Throwable, а не просто Exception. Конструкторы Exception и Error принимают любой экземпляр Throwable как предыдущее исключение.
Throwable может быть использован в блоке try/catch для отлова и Exception и Error (и любых других возможных в будущем исключений). Помните, что хорошей практикой является «ловля» исключений определенным классом исключений и обработка каждого типа отдельно. Но и иногда требуется отлавливать любое исключение. В PHP 7 try/catch блок для всех исключений должен использовать Throwable вместо Exception.
Пользовательские классы не могут реализовывать Throwable. Это было сделано для предсказуемости: только экземпляры Exception или Error могут быть брошены. Кроме того, исключения содержат информацию о том, где объект был создан в stack trace. В пользовательских классах нет необходимых параметров, для хранения этой информации.
Error
Практически все ошибки (E_ERROR, E_RECOVERABLE_ERROR) в PHP 5.x, в PHP 7 выбрасывается экземпляром Error. Как и любые другие исключения, Error может быть пойман используя try/catch блок.
Большинство ошибок, которые были «фатальны» в PHP 5.x в PHP 7 буду выбрасывать простые Error объекты, но некоторые будут выбрасывать объекты подклассов: TypeError, ParseError и AssertionError.
TypeError
Экземпляр TypeError выбрасывается, когда аргументы метода или возвращаемое значение не совпадает с объявленным типом.
ParseError
ParseError выбрасывается, когда подключаемый (путем include/require) файл или код в eval содержит ошибки синтаксиса.
AssertionError
Когда условие, заданное методом assert() не выполняется, выбрасывается AssertionError:
Метод assert() выполняется и выбрасывается AssertionError только, если они включены в настройках: zend.assertions = 1 и assert.exception = 1.
Использование Error в своём коде
Мы можем использовать класс Error, а также расширить Error, создав собственную иерархию класса Error. Это порождает вопрос: какие исключение должен выбрасывать Exception, а какие Error?
Error должен использоваться для указания проблем в коде, требующих внимания программиста (такие как неправильный тип входящих данных и синтаксические ошибки). Exception должен использоваться, когда исключение может «безопасно» обработаться, и выполнение программы может продолжиться.
Поскольку, объекты Error не могут быть обработаны во время выполнения программы, «ловля» Error должна быть редкостью. В целом, Error должны быть пойманы только для логирования их, необходимой «чистки данных», и отображения ошибки для пользователя.
set_exception_handler
set_exception_handler — Задаёт пользовательский обработчик исключений
Описание
Задаёт обработчик по умолчанию для случаев, когда исключение выброшено вне блока try/catch. После вызова callback выполнение будет остановлено.
Список параметров
Указание типа Exception для параметра ex в вашей функции-обработчике приведёт к проблемам в PHP 7 из-за изменённой иерархии классов исключений.
Возвращаемые значения
Примеры
Пример #1 Пример использования set_exception_handler()
throw new Exception ( ‘Неперехваченное исключение’ );
echo «Не выполнено\n» ;
?>
Смотрите также
User Contributed Notes 19 notes
Things you should be aware of:
Since it has not been catched your code signals it is not being aware of the situation and cant go on.
This implies: returning to the script is simply impossible when the exception handler has already been called, since an uncaught exception is not a notice. use your own debug- or notice-log-system for things like that.
Furthermore: While is is still possible to call functions from your script, since the exception handler has already been called exceptions bubbling from that piece of code won’t trigger the exception handler again. php will die without leaving any information apart form «uncaught exception with unknown stack frame». So if you call functions from your script, make sure that you catch any exceptions that possibly occur via try..catch inside the exception handler.
For those of you who misinterpreted the essential meaning of the exception handler: it’s only use is to handle the abortion of your script gracefully, e.g. in a project like facebook or wikipedia: render a nice error page, eventually hiding information which shall not leak into the public (instead you may want to write to your log or mail the sys-admin or stuff like that).
If you want a class instance to handle the exception, this is how you do it :
$example = new example ;
?>
See the first post (Sean’s) for a static example. As Sean points out, the exception_handler function must be declared public.
A behaviour not documented or discussed enough, yet pretty common is that is that if an exception is thrown from the global exception handler then a fatal error occurs (Exception thrown without a stack frame). That is, if you define your own global exception handler by calling set_exception_handler() and you throw an exception from inside it then this fatal error occurs. It is only natural though, as the callback defined by set_exception_handler() is only called on uncaught (unhandled) exceptions so if you throw one from there then you get this fatal error as there is no exception handler left (you override the php internal one by calling set_exception_handler()), hence no stack frame for it.
throw new Exception ( «This should cause a fatal error and this message will be lost» );
?>
Will cause a Fatal error: Exception thrown without a stack frame
If you skip/comment the set_exception_handler(«. «) line then the internal PHP global handler will catch the exception and output the exception message and trace (as string) to the browser, allowing you to at least see the exception message.
While it is a very good idea to always define your own global exception handler by using the set_exception_handler() function, you should pay attention and never throw an exception from it (or if you do then catch it).
Finally, every serious coder should use an IDE with debugging capabilities. Tracking down an error like this becomes a trivial matter by using simple debugging «Step into» commands (I for one recommend Zend IDE v5.2 at the moment of this writing). I have seen numerous messages on the internet with people wondering why this message pops up.
p.s. Other causes for this error which are somehow unrelated to this is when you throw an exception from a destructor (the reasons behind that are similar though, the global handler might no longer exist due to the php engine shutting the page down).
Hey all, i’ve just started to use the exception suite instead of the normal PHP error suite. For those of you looking for an object orientated way to do this without looking down at Glen and Sean’s examples (Lesson 1: ALWAYS read the logs!), here you go:
?>
Let me know if i’m missing something obvious as I left my glasses at home and I just came back from the Melbourne cup (If I won then I wouldn’t be at work still!).
If you’re handling sensitive data and you don’t want exceptions logging details such as variable contents when you throw them, you may find yourself frustratedly looking for the bits and pieces that make up a normal stack trace output, so you can retain its legibility but just alter a few things. In that case, this may help you:
// these are our templates
$traceline = «#%s %s(%s): %s(%s)» ;
$msg = «PHP Fatal error: Uncaught exception ‘%s’ with message ‘%s’ in %s:%s\nStack trace:\n%s\n thrown in %s on line %s» ;
I’ve been messing around with this function, and have noticed you can pass an anonymous function (created with create_function()) through as the default handler, for example:
set_exception_handler(create_function(‘$e’, ‘exit(«An unknown error occurred»);’));
That snippet of code can be used if you simply want to suppress all exceptions that are not handled. This can be a great thing, because secure data could possibly be leaked otherwise (for example, the default exception handler could output a snippet of your SQL code that was involved with the exception being thrown).
You will want to use this wisely, however (if at all).
Your exception handler is configured to be the handler for all exceptions, yet if a basic ‘Exception’ is thrown, your static method will error because ‘Exception’s do not have ‘getException’. Because of this I don’t see a real purpose to making the uncaught handler a class that extends Exception.
I do like the idea of using static methods of a general Exception handling class.
There are much more interesting things that can be done like reformating and optionally displaying or emailing them. But this class acts a nice container for those functions.
For those of you wanting to convert PHP errors to ErrorExceptions (useful), but frustrated with the script being halted on every E_NOTICE et al. In your error handler, simply create the ErrorException, and then either throw it (script halted), or pass the object directly (script continues) to your exception handler function.
const EXIT_ON_ALL_PHP_ERRORS = false ; // or true
On GNU/Linux, When an exception handler is called, PHP will end with exit status code 0 instead of 255.
You can change the exit status code with an exit() call at the end of your custom error handler.
Thanks to mastabog we know that throwing an exception within the exception handler will trigger a fatal error and a debugging nightmare. To avoid throwing an exception within there should be easy.
However, if you use a custom error handler to convert errors to ErrorExceptions suddenly there are a multitude of new ways to accidentally throw exceptions within the exception handler.
This speeds up debugging and offers some scalability to any other exceptions accidentally thrown within the exception handler.
Another solution is to restore the error handler at the beginning of the exception handler. While this is a silver bullet in terms of avoiding the ErrorExceptions, debugging messages then rely on the error_reporting() level and the display_errors directive. Why mention this? It might be preferable for production code since we care more about hiding errors from users than convenient debugging messages.
Using the ‘set_exception_handler’ function within a class, the defined ‘exception_handler’ method must be declared as ‘public’ (preferrable ‘public static’ if you use the «array(‘example’, ‘exception_handler’)» syntax).
$example = new example ;
echo «Not Executed\n» ;
?>
Declaring the ‘exception_handler’ function as ‘private’ causes a FATAL ERROR.
[derick: red. updated statement about static a bit]
As of PHP 7.4, an exception thrown within the user-defined shutdown function can be caught by the user-defined exception handler.
Output: Fatal error: Exception thrown without a stack frame in Unknown on line 0
Fatal error: Uncaught exception ‘ErrorException’ with message ‘Undefined variable: undefined’ in C:\Apache2\htdocs\error\test.php:13 Stack trace: #0 C:\Apache2\htdocs\error\test.php(13): error_handler(8, ‘Undefined varia. ‘, ‘C:\Apache2\htdo. ‘, 13, Array) #1 [internal function]: exception_handler(Object(Exception)) #2
So it appears that exceptions thrown within exception handler now bypass exception handler.
This seems not to work when calling the PHP binary with the ‘-r’ flag.
For example, if I run it like this:
throw new Exception(«Uncaught Exception»);
echo «Not Executed\n»;
‘
Or if I place it in a file and run it like this:
I get a stack trace instead of having the function ‘exception_handler’ called. If run it like this:
(Why run code from ‘-r’? Sometimes it’s useful to add stuff around the include like calls to microtime for benchmarks, or to include a library and then call a few functions from the library, all in an ad-hoc way without having to create new files.)
PHP versions 5.1.2 and 5.0.4.
When an uncaught exception is handled, execution does NOT return to the script, but rather (unexpectedly, on my end anyway) terminates.
I am using set_error_handler() and set_exception_handler() in conjunction for a system I am currently developing (on v5.3.0 with Xampp). Lets say two E_USER_NOTICES are triggered, the script will die after the first one is processed.
It is only printed ONCE. I’ve tried a number of different things, but I can’t figure out how to return execution to the script after the EXCEPTION HANDLER has run.
If anyone has a solution on how to return execution (hence, allow the script to log uncaught exceptions but continue processing) then PLEASE email me! Thanks!
Hi everyone. I don’t know if it is an old behavior of previous versions, but currently you can set exception and error handlers as private or protected methos, if, only if, you call `set_exception_handler()` or `set_error_handler()` within a context that can access the method.
In my experience, the static keyword is crucial for error handlers which are methods of a class instead of free-standing functions.
static function exceptionHandler($exception)
doesn’t and results in a «Fatal error: Exception thrown without a stack frame in Unknown on line 0» message.
«public» is optional as it is the default anyway (but it is probably clearer to write it explicitly).
Правильное использование Exception’ов в PHP
Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.
Почему мы не умеем пользоваться эксепшенами:
PHP — это чрезмерно любящая мать. И при отсутствии строгого отца (например, Java ) или самодисциплины, разработчик вырастет эгоистом, которому плевать на все правила, стандарты и лучшие практики. И вроде бы E_NOTICE пора включать, а он все на мать надеется. Которая, между прочим, стареет — ей уже E_STRICT c E_DEPRICATED нужны, а сынуля все на шее висит.
И пока наш начинающий разработчик пытается написать свою первую быдло-cms, он ни разу не встретиться с механизмом эксепшенов. Вместо этого, он придумает несколько способов обработки ошибок. Я думаю, все понимают о чем я — эти методы, возвращающие разные типы (например, объект при успешном выполнении, а при неудаче — строка с ошибкой), или запись ошибки в какую-либо переменную/свойство, и всегда — куча проверок чтоб передать ошибку вверх по стеку вызовов.
Затем он научиться отлавливать и обрабатывать их. И на этом его знакомство c эксепшенами закончиться. Ведь надо работать, а не учиться: знаний ему и так хватает (сарказм)!
Но самое ужасное — вырабатывается отношение к эксепшенам как к чему-то плохому, нежелательному, опасному, чего быть не должно, и чего нужно всеми способами избежать. Это абсолютно не правильный подход.
Преимущества эксепшенов
На самом деле использование эксепшенов — крайне лаконичное и удобное решение создания и обработки ошибок. Приведу наиболее значимые преимущества:
Контекстная логика
Прежде всего, хотелось бы показать что эксепшн — это не всегда только ошибка (как обычно ее воспринимают разработчики). Иногда он может быть частью логики.
Например, есть у нас функция чтения JSON объекта из файла:
Допустим мы пытаемся прочитать какие-то ранее загруженные данные. При такой операции эксепшн FileNotFoundException не является ошибкой и вполне допустим: возможно, мы ни разу не загружали данные, поэтому файла и нет. А вот JsonParseException — это уже признак ошибки, ибо данные были заргужены, обработаны, сохранены в файл, но почему-то сохранились не правильно.
Совсем другое дело, когда мы пытаемся прочитать файл, который должен быть всегда: при такой операции FileNotFoundException так же является сигналом ошибки.
Таким образом, эксепшены позволяют нам определять логику их обработки в зависимости от контекста, что очень удобно.
Упрощение логики и архитектуры приложения
Попробуйте использовать эксепшены, и вы увидите как ваш код станет более лаконичным и понятным. Исчезнут все костыльные механизмы, возможно, уберутся куча вложенных if’ов, различные механизмы передачи ошибки вверх по стеку вызова, логика станет более простой и прямолинейной.
Места вызовы эксепшенов помогут вашему коллеге лучше понять бизнес логику и предметную область, ибо копаясь в вашем коде он сразу увидит что допустимо, а что нет.
И, если рассматривать какой-либо самодостаточный кусок кода, например, компонента, то список бросаемых им эксепшенов выполняет еще одну важную вещь: дополняет интерфейс этого компонента.
Пользуясь сторонними компонентами мы привыкли обращать внимание только на положительную сторону — на то, что он умеет. При этом обычно не думаем о исключениях, которые он может создать в процессе работы. Список эксепшенов сразу предупреждает где, когда, и какие проблемы могут возникнуть. А предупрежден — значит вооружен.
Вот пример информативного интерфейса, который дополнен знаниями об эксепшенах:
Использование объектов
Использование определенного класса в качестве ошибки — очень удобное решение. Во первых, класс невозможно перепутать: взгляните на 2 способа обработки ошибки:
В первом варианте элементарная опечатке сломает вам всю логику, во втором же ошибку сделать просто невозможно.
Второе преимущество — класс эксепшена инкапсулирует все необходимые данные для его обработки. Например, AddressNotFoundException мог бы выглядеть следующим образом:
Как видим — эксепшн содержит адрес, который не удалось найти. Обработчик может его получить и выполнить на основании его какую-то свою логику.
Третье преимущество — это, собственно, все преимущества ООП. Хотя эксепшены, как правило, простые объекты, поэтому возможности ООП мало используются, но используются.
Например, у меня в приложении порядка 70 классов эксепшенов. Из них несколько — базовых — по одному классу на модуль. Все остальные — наследуются от базового класса своего модуля. Сделано это для удобства анализа логов.
Так же я использую несколько ИНТЕРФЕЙС-МАРКЕРОВ:
Обработчик по умолчанию, логирование
Этот обработчик позволяет нам выполнить различные действия перед остановкой скрипта. Самое главное что нужно сделать, это:
Откат изменений: так как операция не выполнена до конца, необходимо откатить все сделанные изменения. В противном случае мы испортим данные. Например, можно в CController::beforeAction() открыть транзакцию, в CController::afterAction() коммитить, а в случае ошибки сделать роллбэк в обработчике по умолчанию.
Это довольно грубый способ отката, плюс зачастую откат подразумевает не только откат транзакций, и знания о том, как правильно откатывать должны находиться в коде бизнес логики. В таких ситуациях следует воспользоваться вот таким приемом:
Получается что мы откатили изменения и бросили тот же эксепшн, что продолжить его обработку.
Логирование: так же обработчик по умолчанию позволяет нам выполнить какое-то кастомное логирование. Например, в моем приложении я все складываю в базу и использую собственное средство для анализа. На работе мы используем getsentry.com/welcome. В любом случае, эксепшн, дошедший до обработчика по умолчанию — скорее всего непредусмотренный эксепшн, и его необходимо логировать. Следует отметить, что в класс эксепшена можно добавить различную информацию, которую необходимо логировать для большего понимания причины возникновения ошибки.
Невозможность не заметить и перепутать
Огромным плюсом эксепшена является его однозначность: его не возможно не заметить и не возможно с чем-то спутать.
Из первого следует что мы всегда будем осведомлены о возникшей ошибке. И это замечательно — всегда лучше знать о проблеме, чем не знать.
Второй плюс становится очевиден в сравнении с кастомными методами обработки ошибки, например когда метод возвращает null если не нашла нужный объект и false в случае ошибки. В таком случае элементарно не заметить ошибку:
Эксепшн же невозможно пропустить.
Прекращение ошибочной операции
Но самое главное, и самое важное, что делает эксепшн — это прекращает дальнейшее выполнение операции. Операции, которая уже пошла не так. И, следовательно, результат которой непредсказуем.
Огромный минус самопальных механизмов обработки ошибок — необходимость самостоятельно проверять возникновение ошибки. Например, после каждой операции нам нужно писать что то типа:
В итоге, проверки не делаются, и выполнение операции приводит к совершенно неожиданным результатам: вместо одного пользователя удаляются все, деньги пересылаются не тому человеку, голосования в госдуме выдает ложный результат — подобное я видел десятки раз.
Эксепшн защищает нас от подобных проблем: он либо ищет соответствующий обработчик ( его наличие означает что разработчик предусмотрел данную ситуацию, и все нормально), либо доходит до обработчика по умолчанию, который может откатить все изменения, залогировать ошибку, и выдать соответствующее предупреждение пользователю.
Когда следует вызывать эксепшены:
С преимуществами вроде разобрались. Надеюсь, я сумел показать что эксепшены являются крайне удобным механизмом.
Встает вопрос: в каких ситуациях стоит вызывать эксепшн?
Если кратко — всегда! Если подробно: всегда, когда ты уверен что операция должна выполниться нормально, но что-то пошло не так, и ты не знаешь что с этим делать.
Посмотрим на простейший экшн добавления записи:
Когда мы введем некорректные данные поста эксепшн не вызывается. И это вполне соответствует формуле:
Сама кнопка отмены показывается только тогда, когда заказ возможно отменить. Таким образом, когда вызывается этот метод, я уверен, что операция должна пройти успешно (в противном случае кнопка бы не отобразилась, и пользователь не смог бы нажать на нее для вызова этого метода).
Первым делом идет предвалидация — мы проверяем действительно ли мы можем выполнить операцию. В теории все должно пройти успешно, но если isAllowedStatus вернет false — значит что-то пошло не так. Плюс, в пределах текущего метода, мы абсолютно не знаем как обработать эту ситуацию. Понятно, что нужно залогировать ошибку, вывести ее пользователю, и т.п… Но в контексте именно этого метода мы не знаем что с ней делать. Поэтому бросаем эксепшн.
Далее идет выполнение операции и сохранение изменений.
Затем идет поствалидация — мы проверяем, действительно ли все сохранилось, и действительно ли статус изменился. На первый взгляд это может показаться бессмысленным, но: заказ вполне мог не сохранится (например, не прошел валидацию), а статус вполне мог быть изменен (например, кто-то набыдлокодил в CActiveRecord::beforeSave ). Поэтому эти действия необходимы, и, опять-таки, если что-то пошло не так — бросаем эксепшн, так как в пределах данного метода мы не знаем как обрабатывать эти ошибки.
Эксепшн vs возврат null
Следует отметить, что эксепшн следует бросать только в случае ошибки. Я видел как некоторые разработчики злоупотребляют ими, бросая их там, где не следовало бы. Особенно часто — когда метод возвращает объект: если не получается вернуть объект — бросается эксепшн.
Тут следует обратить внимание на обязанности метода. Например, СActiveRecord::find() не бросает эксепшн, и это логично — уровень его “знаний” не содержит информации о том, является ли ошибкой отсутствие результата. Другое дело, например, метод KladrService::resolveAddress() который в любом случае обязан вернуть объект адреса (иначе либо код неправильный, либо база не актуальная). В таком случае нужно бросать эксепшн, ибо отсутствие результата — это ошибка.
В целом же, описанная формула идеально определяет места, где необходимо бросать эксепшены. Но особо хотелось бы выделить 2 категории эксепшенов, которых нужно делать как можно больше:
Технические эксепшены
Это эксепшены, которые абсолютно не связанны с предметной областью, и необходимы чтобы чисто технически предотвратить выполнение неверной логики.
Вот несколько примеров:
Технические эксепшены помогут не допустить или отловить, имхо, большую часть багов в любом проекте. И неоспоримым плюсом их использования является отсутствие необходимости понимать предметную область: единственное что требуется — это дисциплина разработчика. Я призываю не лениться и вставлять такие проверки повсеместно.
Эксепшены утверждений
Эксепшены утверждений (по мотивам DDD ) вызываются когда мы обнаруживаем что нарушается какая-либо бизнес-логика. Безусловно, они тесно связанна с знаниями предметной области.
Они бросаются когда мы проверяем какое-либо утверждение, и видим что результат проверки не соответствует ожидаемому.
Например, есть метод добавления позиции в заказ:
В процессе добавления позиции происходит куча различных действий. И при этом периодически проверяются различные утверждения: что все суммы сходятся, что заказ может быть доставить — это и есть эксепшены утверждений.
Здесь можно подискутировать на тему необходимости подобных эксепшенов:
Например, можно написать тесты на методы перерасчета стоимости заказа, и проверка в теле метода — не более чем дублирование теста. Можно проверять возможность доставки заказа с новой позицией до добавления позиции (чтоб предупредить об этом пользователя, как минимум)
Но практика показывает, что далеко не всегда удается написать тесты для всех инвариантов объекта. И невозможно защититься от, например, нового разработчика, который может накодить все что угодно.
Поэтому в критичных местах такие эксепшены нужны однозначно.
Изменение логики для избегания эксепшна
Как я уже говорил, PHP разработчики боятся эксепшенов. Они боятся их появления, и боятся бросать их самостоятельно.
И в этой борьбе с эксепшенами многие допускают ошибку: отступают от изначально четкой, понятной, прямолинейной логики в сторону каких-либо допущений, чтобы хоть как-то выполнить операцию.
Вот пример: необходимо просто отобразить страницу по id (чтоб вы понимали — это реальный код из известного проекта)
Несмотря на простейшую и понятную задачу — здесь совершенно дикая логика.
Мало того, что она может показать пользователю совершенно не то что надо, так она еще и маскирует наши баги:
Тоже из реального проекта, и мотивация такая-же: вернуть хоть что-то, но не вызывать эксепшн, несмотря на то, что метод явно должен возвращать код города, а не региона.
И таких изменений логики в среднестатистическом проекте огромное кол-во. Пока ты помнишь об этом — это кажется безобидным. Но как только забываешь, или подключается другой разработчик — баг обеспечен. Причем неявный баг, плавающий.
Мое мнение — это недопустимо. Просто когда ты работаешь с большими деньгами (а я с ними работал довольно долго), вырабатывается определенные правила, и одно из них — прерывать операцию в случае любого подозрения на ошибку. Транзакция на 10 млн баксов: согласитесь, ее лучше отменить, чем перечислить деньги не тому человеку.
Конечно, обычно мы имеем дело с менее рискованными операциями. И в случае бага, например, инвалид не сможет оставить заявку на установку пандуса в подъезде. И разработчик на раслабоне (его ведь даже не оштрафуют) пренебрегает этими элементарными правилами, мол, подумаешь, мелочь какая. Проблема в том, что когда ему доверят что-то критически важное — вряд ли его подход измениться. Ибо проблема не в знаниях, и не в риске, а в дисциплине и в отношении к делу. И получается, что после таких программистов у нас где-то трубы зимой лопаются, где-то нефть разливается тоннами, где-то люди умирают десятками, где-то деньги воруются миллионами. Подумаешь, мелочь какая!
Собачки
Собачки вместо isset используют для лаконичности кода:
Действительно, выглядит намного короче, и на первый взгляд результат такой же. Но! опасно забывать что собачка — оператор игнорирования сообщений об ошибках. И @$policy->owner->address->locality вернет null не потому-что проверит существование цепочки объектов, а потому-что просто проигнорирует возникшую ошибку. А это совершенно разные вещи.
Проблем в том, что помимо игнорирования ошибки Trying to get property of non-object (которое и делает поведение собачки похожим на isset ), игнорируются все другие возможные ошибки.
PHP — это магический язык! При наличии всех этих магических методов ( __get, __set, __call, __callStatic, __invoke и пр.) мы не всегда можем сразу понять что происходит на самом деле.
Таким образом, столь необдуманное использование собачки потенциально создает огромное кол-во проблем.
Послесловие
Но попробуйте собрать конструктор без инструкции… Эта мысль похожа на бред. Тем не менее, программисты без всех этих знаний прекрасно работают. Годами. И им это не кажется бредом — они даже не понимают, что что-то делают не так. Вместо этого они жалуются что им дали слишком мало времени.
И если в послесловии предыдущего поста я предлагал задуматься, надеясь что кто-то изменит свой код к лучшему, то теперь я потерял эту надежду. Видимо, люди действительно ценят только тот опыт, за который заплатили.
Так что всем, кто прочел этот пост и подумал “что за бред”, “я все это знаю, но применять лень”, или “будет сосунок мне указывать” — я желаю совершить баг. Баг, за который оштрафуют или уволят. И тогда вы, возможно, вспомните этот пост, и задумаетесь: “возможно я и в правду что-то делаю не так”?
Совершите его как можно скорее. Ибо лучше один раз ошибиться, но прозреть, чем всю жизнь прожить быдлокоддером. Аминь.