php error get last
posix_get_last_error
(PHP 4 >= 4.2.0, PHP 5, PHP 7, PHP 8)
posix_get_last_error — Возвращает номер ошибки, которая произошла в последней posix функции, завершившейся неудачей
Описание
Список параметров
У этой функции нет параметров.
Возвращаемые значения
Возвращает номер ошибки, установленный последней posix функцией, завершившейся неудачей. В случае отсутствия ошибок возвращает 0.
Примеры
Пример #1 Пример использования posix_get_last_error()
В данном примере происходит попытка завершить несуществующий процесс по его id. Попытка завершается неудачей и возвращает номер ошибки, который будет выведен.
Смотрите также
User Contributed Notes 1 note
Many posix functions give very useful information in the errno code when an error occurs. For instance, stream_select(), when it generates an error, according to the man page (man 2 select) may return one of four different errors which are listed as: EBADF, EINTR, EINVAL, ENOMEM. See the man page for more specific information about these. In this example, when the stream_select() function returns false, posix_get_last_error() will return a non-zero value that will be set to one of these constants. For instance, if stream_select() == false, and posix_get_last_error() == EBADF, then one of the file descriptors given to the select() function has probably closed somehow. If, on the other hand, posix_get_last_error() returns EINTR then stream_select() returned FALSE not because of any true error condition, but only because the process handled a signal. When the signal arrives while stream_select() is blocking it will always stop blocking and return false immediately. This behavior makes sense, though it can seem inconvenient. You just have to handle it correctly. (not many do, in php.)
From this example it should probably be clear that one should at least consider handling different error types in different ways. EINTER should probably be ignored for instance, unless your program uses signalling to open or close file handles or sockets.
These error constants listed in the related POSIX man pages are not part of the PHP interface. When you call posix_get_last_error() it will return an integer. The problem with getting an unnamed integer return code is that these integers may mean different things on different systems. You can (and probably should) pass the resulting integer to the posix_strerror() function, which will return an accurate human-readable description of what the error is. This is useful of course, but mainly for logging. (String descriptions of errors are far more prone to change than are the actual integer value codes.) Truly, when using the result of posix_errno() it is best to check the value against a set of possible constants. The constants you compare them to are system specific, as stated earlier, so you need to look them up on that system. Here is an easy and reliable way to do that.
Look at the errno man page ($ man errno) and copy all of the constant names into a very basic C file. like this.
To finish the example, you might use these constants like this:
error_get_last
(PHP 5 >= 5.2.0, PHP 7, PHP 8)
error_get_last — Получение информации о последней произошедшей ошибке
Описание
Получает информацию о последней произошедшей ошибке.
Список параметров
У этой функции нет параметров.
Возвращаемые значения
Примеры
Пример #1 Пример использования error_get_last()
Результатом выполнения данного примера будет что-то подобное:
Смотрите также
User Contributed Notes 13 notes
[Editor’s note: as of PHP 7.0.0 there is error_clear_last() to clear the most recent error.]
To clear error_get_last(), or put it in a well defined state, you should use the code below. It works even when a custom error handler has been set.
// error_get_last() is now in a well known state:
// Undefined variable: undef_var
Function error_get_last() will return an error information even if the error is hidden because you’ve used character @, because of the «error_reporting» directive in the php.ini file, or because you’ve used function error_reporting().
The error_get_last() function will give you the most recent error even when that error is a Fatal error.
To manual moderators: Re php.net/manual/add-note.php: Since i guess the above technically sorts under «References to other notes» i feel the need to defend myself with that i’m thinking it might show for usability where other’s say it fails and no, i haven’t got any other medium to reach the readers of the php manual notes.
Also, you could have some examples of what notes you think is okay. Thanks for your moderation.
( PHP_VERSION );
// Outputs: string(5) «5.2.6»
Beware that registing a shutdown function to catch errors won’t work if other shutdown functions throw errors.
( ‘cleanupObjects’ );
register_shutdown_function ( ‘handleFatalPhpError’ );
PHP для начинающих. Обработка ошибок
Не совершает ошибок только тот, кто ничего не делает, и мы тому пример — сидим и трудимся не покладая рук, читаем Хабр 🙂
В этой статье я поведу свой рассказа об ошибках в PHP, и о том как их обуздать.
Ошибки
Разновидности в семействе ошибок
Перед тем как приручать ошибки, я бы рекомендовал изучить каждый вид и отдельно обратить внимание на самых ярких представителей.
Чтобы ни одна ошибка не ушла незамеченной потребуется включить отслеживание всех ошибок с помощью функции error_reporting(), а с помощью директивы display_errors включить их отображение:
Фатальные ошибки
Самый грозный вид ошибок — фатальные, они могут возникнуть как при компиляции, так и при работе парсера или PHP-скрипта, выполнение скрипта при этом прерывается.
E_PARSE
Это ошибка появляется, когда вы допускаете грубую ошибку синтаксиса и интерпретатор PHP не понимает, что вы от него хотите, например если не закрыли фигурную или круглую скобочку:
Или написали на непонятном языке:
Лишние скобочки тоже встречаются, и не так важно круглые либо фигурные:
Отмечу один важный момент — код файла, в котором вы допустили parse error не будет выполнен, следовательно, если вы попытаетесь включить отображение ошибок в том же файле, где возникла ошибка парсера то это не сработает:
E_ERROR
Это ошибка появляется, когда PHP понял что вы хотите, но сделать сие не получилось ввиду ряда причин. Эта ошибка так же прерывает выполнение скрипта, при этом код до появления ошибки сработает:
Не был найден подключаемый файл:
Было брошено исключение (что это за зверь, расскажу немного погодя), но не было обработано:
При попытке вызвать несуществующий метод класса:
Отсутствия свободной памяти (больше, чем прописано в директиве memory_limit) или ещё чего-нить подобного:
Очень часто встречается при чтении либо загрузки больших файлов, так что будьте внимательны с вопросом потребляемой памяти
Рекурсивный вызов функции. В данном примере он закончился на 256-ой итерации, ибо так прописано в настройках xdebug (да, данная ошибка может проявиться в таком виде только при включении xdebug расширения):
Не фатальные
Данный вид не прерывает выполнение скрипта, но именно их обычно находит тестировщик. Именно такие ошибки доставляют больше всего хлопот начинающим разработчикам.
E_WARNING
Бывает, если используешь неправильный тип аргументов при вызове функций:
Их очень много, и перечислять все не имеет смысла…
E_NOTICE
Это самые распространенные ошибки, мало того, есть любители отключать вывод ошибок и клепают их целыми днями. Возникают при целом ряде тривиальных ошибок.
Когда обращаются к неопределенной переменной:
Когда обращаются к несуществующему элементу массива:
Когда обращаются к несуществующей константе:
Когда не конвертируют типы данных:
Для избежания подобных ошибок — будьте внимательней, и если вам IDE подсказывает о чём-то — не игнорируйте её:
E_STRICT
Данный тип ошибок актуален для PHP версии 5.6, и практически все их выпилили из
7-ки. Почитать подробней можно в соответствующей RFC. Если кто знает где ещё остались данные ошибки, то напишите в комментариях
E_DEPRECATED
Так PHP будет ругаться, если вы используете устаревшие функции (т.е. те, что помечены как deprecated, и в следующем мажорном релизе их не будет):
В моём редакторе подобные функции будут зачёркнуты:
Пользовательские
Этот вид, которые «разводит» сам разработчик кода, я уже давно их не встречал, и не рекомендую вам ими злоупотреблять:
Теперь, когда вы познакомились с большинством видов и типов ошибок, пора озвучить небольшое пояснение по работе директивы display_errors :
Приручение
Для работы с ошибками в PHP существует 3 функции:
У вас не получится назначить более одной функции для обработки ошибок, хотя очень бы хотелось регистрировать для каждого типа ошибок свой обработчик, но нет — пишите один обработчик, и всю логику отображения для каждого типа описывайте уже непосредственно в нём
С обработчиком, который написан выше есть одна существенная проблема — он не ловит фатальные ошибки, и при таких ошибках вместо сайта пользователи увидят лишь пустую страницу, либо, что ещё хуже, сообщение об ошибке. Дабы не допустить подобного сценария следует воспользоваться функцией register_shutdown_function() и с её помощью зарегистрировать функцию, которая всегда будет выполняться по окончанию работы скрипта:
Данная функция будет срабатывать всегда!
Но вернёмся к ошибкам, для отслеживания появления в коде ошибки воспользуемся функцией error_get_last(), с её помощью можно получить информацию о последней выявленной ошибке, а поскольку фатальные ошибки прерывают выполнение кода, то они всегда будут выполнять роль «последних»:
Хотел обратить внимание, что данный код хоть ещё и встречается для обработки ошибок, и вы возможно вы даже с ним столкнётесь, но он потерял актуальность начиная с 7-ой версии PHP. Что пришло на замену я расскажу чуть погодя.
О прожорливости
Проведём простой тест, и выясним — сколько драгоценных ресурсов кушает самая тривиальная ошибка:
В результате запуска данного скрипта у меня получился вот такой результат:
Теперь добавим ошибку в цикле:
Результат ожидаемо хуже, и на порядок (даже на два порядка!):
Вывод однозначен — ошибки в коде приводят к лишней прожорливости скриптов — так что во время разработки и тестирования приложения включайте отображение всех ошибок!
Тестирование проводил на различных версиях PHP и везде разница в десятки раз, так что пусть это будет ещё одним поводом для исправления всех ошибок в коде
Где собака зарыта
В PHP есть спец символ «@» — оператор подавления ошибок, его используют дабы не писать обработку ошибок, а положится на корректное поведение PHP в случае чего:
Если вы в такой способ подавляете ошибки, то это уменьшает нагрузку на процессор в сравнении с тем, если вы их просто скрываете (см. сравнительный тест выше), но в любом случае, подавление ошибок это зло
Исключения
В эру PHP4 не было исключений (exceptions), всё было намного сложнее, и разработчики боролись с ошибками как могли, это было сражение не на жизнь, а на смерть… Окунуться в эту увлекательную историю противостояния можете в статье Исключительный код. Часть 1. Стоит ли её читать сейчас? Не могу дать однозначный ответ, лишь хочу заметить, что это поможет вам понять эволюцию языка, и раскроет всю прелесть исключений.
Исключения — исключительные событие в PHP, в отличии от ошибок не просто констатируют наличие проблемы, а требуют от программиста дополнительных действий по обработке каждого конкретного случая.
К примеру, скрипт должен сохранить какие-то данные в кеш файл, если что-то пошло не так (нет доступа на запись, нет места на диске), генерируется исключение соответствующего типа, а в обработчике исключений принимается решение — сохранить в другое место или сообщить пользователю о проблеме.
В каких случаях стоит применять исключения:
Соответственно ловить данные исключения будем примерно так:
В данном примере приведен очень простой сценарий обработки исключений, когда у нас любая исключительная ситуация обрабатывается на один манер. Но зачастую, различные исключения требуют различного подхода к обработке, и тогда следует использовать коды исключений и задать иерархию исключений в приложении:
Теперь, если использовать эти исключения то можно получить следующий код:
Важно помнить, что Exception — это прежде всего исключительное событие, иными словами исключение из правил. Не нужно использовать их для обработки очевидных ошибок, к примеру, для валидации введённых пользователем данных (хотя тут не всё так однозначно). При этом обработчик исключений должен быть написан в том месте, где он будет способен его обработать. К примеру, обработчик для исключений вызванных недоступностью файла для записи должен быть в методе, который отвечает за выбор файла или методе его вызывающем, для того что бы он имел возможность выбрать другой файл или другую директорию.
Чтобы избежать подобной ситуации следует использовать функцию set_exception_handler() и установить обработчик для исключений, которые брошены вне блока try-catch и не были обработаны. После вызова такого обработчика выполнение скрипта будет остановлено:
Ещё расскажу про конструкцию с использованием блока finally — этот блок будет выполнен вне зависимости от того, было выброшено исключение или нет:
Для понимания того, что это нам даёт приведу следующий пример использования блока finally :
Т.е. запомните — блок finally будет выполнен даже в том случае, если вы в блоке catch пробрасываете исключение выше (собственно именно так он и задумывался).
Для вводной статьи информации в самый раз, кто жаждет ещё подробностей, то вы их найдёте в статье Исключительный код 😉
PHP7 — всё не так, как было раньше
Так, вот вы сейчас всю информацию выше усвоили и теперь я буду грузить вас нововведениями в PHP7, т.е. я буду рассказывать о том, с чем вы будете сталкиваться работая над современным PHP проектом. Ранее я вам рассказывал и показывал на примерах какой костыль нужно соорудить, чтобы отлавливать критические ошибки, так вот — в PHP7 это решили исправить, но? как обычно? завязались на обратную совместимость кода, и получили хоть и универсальное решение, но оно далеко от идеала. А теперь по пунктам об изменениях:
Сложно? Теперь на примерах, возьмём те, что были выше и слегка модернизируем:
В результате ошибку поймаем и выведем:
И чуть-чуть деталей:
TypeError — для ошибок, когда тип аргументов функции не совпадает с передаваемым типом:
ArithmeticError — могут возникнуть при математических операциях, к примеру когда результат вычисления превышает лимит выделенный для целого числа:
AssertionError — редкий зверь, появляется когда условие заданное в assert() не выполняется:
При настройках production-серверов, директивы zend.assertions и assert.exception отключают, и это правильно
Полный список предопределённых исключений вы найдёте в официальном мануале, там же иерархия SPL исключений.
При написании данного раздела были использованы материалы из статьи Throwable Exceptions and Errors in PHP 7.
Единообразие
— Там ошибки, тут исключения, а можно это всё как-то до кучи сгрести?
Да запросто, у нас же есть set_error_handler() и никто нам не запретит внутри оного обработчика бросить исключение:
Но данный подход с PHP7 избыточен, со всем теперь справляется Throwable :
Отладка
Иногда, для отладки кода, нужно отследить что происходило с переменной или объектом на определённом этапе, для этих целей есть функция debug_backtrace() и debug_print_backtrace() которые вернут историю вызовов функций/методов в обратном порядке:
В результате выполнения функции debug_print_backtrace() будет выведен список вызовов приведших нас к данной точке:
Assert
Функция assert() поменяла своё поведение при переходе от версии 5.6 к 7.0, и ещё сильней всё поменялось в версии 7.2, так что внимательней читайте changelog’и PHP 😉
Первый случай — это когда вам надо написать TODO прямо в коде, да так, чтобы точно не забыть реализовать заданный функционал:
В результате выполнения данного кода получим E_WARNING :
PHP7 можно переключить в режим exception, и вместо ошибки будет всегда появляться исключение AssertionError :
При необходимости, можно выбрасывать произвольное исключение:
Второй вариант использования — это создание некоего подобия TDD, но помните — это лишь подобие. Хотя, если сильно постараться, то можно получить забавный результат, который поможет в тестировании вашего кода:
Третий вариант — некое подобие на контрактное программирование, когда вы описали правила использования своей библиотеки, но хотите точно убедится, что вас поняли правильно, и в случае чего сразу указать разработчику на ошибку (я вот даже не уверен, что правильно его понимаю, но пример кода вполне рабочий):
Если вас заинтересовали контракты, то специально для вас у меня есть ссылочка на фреймворк PhpDeal.
Никогда не используйте assert() для проверки входных параметров, ведь фактически assert() интерпретирует первый параметр (ведёт себя как eval() ), а это чревато PHP-инъекцией. И да, это правильное поведение, ведь если отключить assert’ы, то все передаваемые аргументы будут проигнорированы, а если делать как в примере выше, то код будет выполняться, а внутрь отключенного assert’a будет передан булевый результат выполнения. А, и это поменяли в PHP 7.2 🙂
Если у вас есть живой опыт использования assert() — поделитесь со мной, буду благодарен. И да, вот вам ещё занимательно чтива по этой теме — PHP Assertions, с таким же вопросом в конце 🙂
В заключение
Я за вас напишу выводы из данной статьи:
Это репост из серии статей «PHP для начинающих»:
Спасибо Максиму Слесаренко за помощь в написании статьи.
error_get_last() returns NULL in PHP 7 when a custom exception handler is set
Ok, this took some time to break it down. Here it is:
There is an included faulty script which is the following for the remainder of this post:
faulty.php
Then consider the following script for handling the error. Note, that the custom exception handler is initially not registered.
script.php
Result with no custom exception handler
The results for PHP 5 and 7 are identical. The error_get_last() function returns the last ocurred error (Screenshot).
Result with custom error handler
Now we set a custom function uncommenting the line
This will work fine in PHP 5, however in PHP 7 the error_get_last() function returns NULL (Screenshot).
Question
Why is this? Especially confusing as the custom exception handler is empty, e.g. not «successfully handling» the error.
How to prevent this?
All the best and thanks for hints!
Update: problem and solution
The thing (not really a problem) is that PHP 7 throws an exception of type ParseError rather then producing an error. Thus, it is best handled with an exception handler. Make a nice exception handler to handle the exception well:
1 Answer 1
PHP 7 changes how most errors are reported by PHP. Instead of reporting errors through the traditional error reporting mechanism used by PHP 5, most errors are now reported by throwing Error exceptions.
error_get_last
error_get_last — Получение информации о последней произошедшей ошибке
Описание
Получает информацию о последней произошедшей ошибке.
Возвращаемые значения
Примеры
Пример #1 Пример использования error_get_last()
Результатом выполнения данного примера будет что-то подобное:
Смотрите также
Коментарии
( PHP_VERSION );
// Outputs: string(5) «5.2.6»
While mail at mbaierl dot com makes the point that this function isn’t best for reporting the possible error condition of the most recently executed step, there are situations in which it is especially helpful to know the last error—regardless of when it occurred.
As an example, imagine if you had some code that captured the output from dynamic pages, and cached it for faster delivery to subsequent visitors. A final sanity check would be to see if an error has occurred anywhere during the execution of the script. If there has been an error, we probably don’t want to cache that page.
The error_get_last() function will give you the most recent error even when that error is a Fatal error.
Beware that registing a shutdown function to catch errors won’t work if other shutdown functions throw errors.
( ‘cleanupObjects’ );
register_shutdown_function ( ‘handleFatalPhpError’ );
If you have the need to check whether an error was a fatal error before PHP 5.2 (in my case, within an output buffer handler), you can use the following hack:
Function error_get_last() will return an error information even if the error is hidden because you’ve used character @, because of the «error_reporting» directive in the php.ini file, or because you’ve used function error_reporting().
To manual moderators: Re php.net/manual/add-note.php: Since i guess the above technically sorts under «References to other notes» i feel the need to defend myself with that i’m thinking it might show for usability where other’s say it fails and no, i haven’t got any other medium to reach the readers of the php manual notes.
Also, you could have some examples of what notes you think is okay. Thanks for your moderation.
[Editor’s note: as of PHP 7.0.0 there is error_clear_last() to clear the most recent error.]
To clear error_get_last(), or put it in a well defined state, you should use the code below. It works even when a custom error handler has been set.
// error_get_last() is now in a well known state:
// Undefined variable: undef_var