3

I moved a file in our system to a sub folder for organization, which in turn broke a require statement's relative path. This should have resulted in a E_COMPILE_ERROR warning. However, instead of that error, our custom error handler in the application caught the error as a E_WARNING. So, our customer handler logged the message and the resulting PHP Screen came up empty, as if die(); was run. Here is the log created by our local handler:

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

It may be important to note that our system is still using poor old PHP 4.

Any idea why require would throw an E_WARNING? This took a bit longer to figure out what the issue was, since we couldn't see any error message.

Edit: The application was definitely doing a require. The custom error handler is simply using PHP's set_error_handler function. So it shouldn't be called for anything other than warnings, notices, and user errors.

Additional Edit:

Maybe the structure has something to do with this? Here's how its working: (-> means includes, => means requires)

main->File1.php=>File2.php

Does it throw a warning because File1.php is included, but not required? This might make sense to me, but would appear to be a glitch? I might need to test this on PHP 5.

RESOLUTION

I've scanned through our application and found this:

error_reporting(E_ERROR | E_WARNING | E_PARSE);

Therefore, E_COMPILE_ERROR will not show up. Furthermore, @DaveRandom is correct about it throwing a warning, then throwing a fatal error.

Changing it to error_reporting(E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR); shows the error message.

teynon
  • 7,540
  • 10
  • 63
  • 106
  • Without seeing your custom error handler, no way to tell. a failed require should spit out a compile error, but since you're doing custom work, check that it's actually working (failing?) properly. – Marc B Jan 26 '12 at 15:53
  • make sure you dont have a @ sign at your require statement, which suppresses error reporting. – ncank Jan 26 '12 at 16:08

2 Answers2

2

Require emits this warning at least once when you call it on a file that does not exist. It then emits an E_COMPILE_ERROR and dies.

However:

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

So your custom error handler will never catch the error I'm afraid.

DaveRandom
  • 87,921
  • 11
  • 154
  • 174
  • I know it shouldn't catch the E_COMPILE_ERROR. However, all other fatal errors are displayed on screen, via PHP's error_reporting settings. I might need to set up a test for this. – teynon Jan 26 '12 at 16:04
  • I've scanned through our application and found this: error_reporting(E_ERROR | E_WARNING | E_PARSE); Therefore, E_COMPILE_ERROR will not show up. Furthermore, @DaveRandom is correct about it throwing a warning, then throwing a fatal error. – teynon Jan 26 '12 at 17:20
0

Is it indeed doing a require? The E_WARNING seems to imply you use include instead of require there... or perhaps PHP4 behaved differently with regards to this? I honestly can not remember.

skoop
  • 198
  • 5