set_error_handler
перехватывает сообщения, отправленные во время выполнения, в соответствии с документы:
Эту функцию можно использовать для определения собственного способа обработки ошибок во время выполнения.
Предупреждение об устаревании, которое вы видите, реализовано во время компиляции., что по определению происходит перед выполнением:
static zend_op *zend_delayed_compile_dim(znode *result, zend_ast *ast, uint32_t type) /* {{{ */
{
if (ast->attr == ZEND_DIM_ALTERNATIVE_SYNTAX) {
zend_error(E_DEPRECATED, "Array and string offset access syntax with curly braces is deprecated");
}
...
Вы можете думать об этом как о «мягкой синтаксической ошибке»: она обнаруживается при синтаксическом анализе, на этапе компиляции, но это не фатальная ошибка, а предупреждение о будущей гибели. Как и синтаксические ошибки, у вас есть два способа их обработки: добавление в начало и обработка завершения работы.
Подготовка
$ cat error-handler.php
<?php
set_error_handler(fn(...$args) => var_dump($args));
$ cat try.php
<?php
$b = 'test';
$a = $b{1};
$ php -d auto_prepend_file=error-handler.php try.php
array(5) {
[0]=>
int(8192)
[1]=>
string(69) "Array and string offset access syntax with curly braces is deprecated"
[2]=>
string(21) "/Users/bishop/try.php"
[3]=>
int(3)
[4]=>
NULL
}
Обработка отключения
register_shutdown_function(fn() => var_dump(error_get_last()));
$b = 'test';
$a = $b{1};
Выходы:
array(4) {
["type"]=>
int(8192)
["message"]=>
string(69) "Array and string offset access syntax with curly braces is deprecated"
["file"]=>
string(9) "/in/212CF"
["line"]=>
int(7)
}
Что использовать?
Выберите один или оба, в зависимости от ваших потребностей. Лично я использую подход prepend, так как он обрабатывает различные другие сценарии белого экрана смерти. Если вы делаете это в веб-контексте, вам нужно настроить свой веб-сервер для установки параметра auto_prepend_file
: после запуска вашего «основного» кода вы не можете установить prepend и заставить его работать, как показано здесь.
person
bishop
schedule
07.01.2020
include
для включения файла, вызывающего предупреждение, после установки обработчика ошибок в родительском скрипте. Кажется, что это работает (проверено локально), но непоследовательно (не запускает обработчик ошибок при последующих выполнениях, как если бы PHP хранил локальный кеш или что-то в этом роде - отредактируйте: да) и в любом случае своего рода уловка. Не уверен, что с этим можно что-то еще сделать. - person Jeto   schedule 07.01.2020$b = 'test'; $a = $b{1};
, предупреждение останется прежним. Единственная разница заключается в файле и строке находки. - person Dave   schedule 07.01.2020set_error_handler()
: Следующие типы ошибок не могут быть обработаны пользовательской функцией: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING и большая часть E_STRICT, возникших в файле. где вызывается set_error_handler(). Таким образом, вы не должны полагаться на него как на способ сокрытия ошибок от пользователей. - person Barmar   schedule 07.01.2020