Оператор PHP require - сбой, но выдает E_WARNING вместо E_COMPILE_ERROR

Я переместил файл в нашей системе в подпапку для организации, что, в свою очередь, нарушило относительный путь оператора require. Это должно было привести к предупреждению E_COMPILE_ERROR. Однако вместо этой ошибки наш пользовательский обработчик ошибок в приложении перехватил ошибку как E_WARNING. Итак, наш клиентский обработчик зарегистрировал сообщение, и результирующий PHP-экран оказался пустым, как если бы был запущен die();. Вот журнал, созданный нашим локальным обработчиком:

E_WARNING main(XXXXXX.php): failed to open stream: No such file or directory xxx/xxx.php Line 9 01-26-2012 09:44:27 AM 01-26-2012 10:03:24 AM

Возможно, важно отметить, что наша система все еще использует старый бедный PHP 4.

Любая идея, почему require выдает E_WARNING? Это заняло немного больше времени, чтобы выяснить, в чем проблема, так как мы не могли видеть никаких сообщений об ошибках.

Изменить: приложение определенно требовало. Пользовательский обработчик ошибок просто использует функцию PHP set_error_handler. Поэтому его не следует вызывать ни для чего, кроме предупреждений, уведомлений и пользовательских ошибок.

Дополнительное редактирование:

Может быть, структура как-то связана с этим? Вот как это работает: (-> значит включает, => значит требует)

главная->Файл1.php=>Файл2.php

Выдает ли предупреждение, потому что File1.php включен, но не требуется? Это может иметь смысл для меня, но может показаться, что это глюк? Мне может понадобиться проверить это на PHP 5.

РАЗРЕШЕНИЕ

Я просмотрел наше приложение и нашел это:

error_reporting (E_ERROR | E_WARNING | E_PARSE);

Поэтому E_COMPILE_ERROR не появится. Кроме того, @DaveRandom прав в том, что он выдает предупреждение, а затем выдает фатальную ошибку.

Изменение его на error_reporting(E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR); показывает сообщение об ошибке.


error-handling php require php4
person teynon    schedule 26.01.2012    source источник
comment
Не видя вашего пользовательского обработчика ошибок, невозможно сказать. неудачный запрос должен выдавать ошибку компиляции, но, поскольку вы выполняете нестандартную работу, убедитесь, что она действительно работает (не работает?) правильно.   -  person Marc B    schedule 26.01.2012
comment
убедитесь, что у вас нет знака @ в вашем запросе, который подавляет сообщения об ошибках.   -  person ncank    schedule 26.01.2012

Ответы (2)


arrow_upward
2
arrow_downward

Require выдает это предупреждение по крайней мере один раз, когда вы вызываете его для несуществующего файла. Он затем выдает E_COMPILE_ERROR и умирает.

Однако:

Следующие типы ошибок не могут быть обработаны с помощью определяемой пользователем функции: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING и большинство ошибок E_STRICT, возникающих в файле, где вызывается set_error_handler().

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

person DaveRandom    schedule 26.01.2012
comment
Я знаю, что он не должен перехватывать E_COMPILE_ERROR. Однако все другие фатальные ошибки отображаются на экране через настройки PHP error_reporting. Возможно, мне нужно настроить тест для этого. - person teynon; 26.01.2012
comment
Я просмотрел наше приложение и нашел это: error_reporting(E_ERROR | E_WARNING | E_PARSE); Поэтому E_COMPILE_ERROR не появится. Кроме того, @DaveRandom прав в том, что он выдает предупреждение, а затем выдает фатальную ошибку. - person teynon; 26.01.2012

arrow_upward
0
arrow_downward

Это действительно требует? E_WARNING, кажется, подразумевает, что вы используете include вместо require там ... или, возможно, PHP4 вел себя по-другому в отношении этого? честно не помню.

person skoop    schedule 26.01.2012
comment
Это определенно требуется. Я могу воссоздать проблему, добавив файл require обратно. - person teynon; 26.01.2012