Re: Silenced include(_once) calls

Justin Patrin wrote: We have talked about this on multiple occations. My opinion is that you can silence errors as long as you handle them accordingly.

There are several alternatives to silencing include: 1) Leave it as-is but without @. This will cause PHP to display errors when files can't be found, but this is in general something that the developer wanted to see anyway. Remember that production websites should normally have error_reporting turned off and output to a file so that the user doesn't see it.

Sure but what if the include is expected to fail under certain conditions? Like with optional modules. So this is not a 1 size fits all solution. So lets look at the next solutions.

2) Split the include_path and check file_exists and is_readable for the file for each path. This is a solution which adds some extra cycles to the include process but allows the application to gracefully return an error when a file is not includable without a PHP error getting triggered.

Aside from race conditions, which I consider to be irrelevant, file_exists cannot check the include path. This is why I have introduced a custom fileExists() into MDB2 and LiveUser. A patch provided to internals to extend file_exists() was dismissed. file_exists() also does not play well with safe_mode apparently (http://pear.php.net/bugs/bug.php?id=6226) so I tried to work around optional includes as much as possible by letting users explicitly tell me if they have a given optional dependency installed.

3) Use @fopen($file, 'r', true). This is faster than #2 and still checks the include_path. This also does a check for readability in one call. This does use @, but in this case it has no horrible side-effects, such as the script dying. There are a few side-effects in that a registered PHP error handler will catch errors from this, but that is not likely to hurt an application in any way. This solution also allows an application to gracefully return an error without PHP errors being displayed.

fopen() is not a good idea. I talked to Wez about this several years back. It creates locking issues or something like that. I do not remember the details. So to conclude: Internals has decided to totally ignore the idea of dynamic includes. Which makes the existance of include[_once] so laughable. Whenever anyone has brought up the limitations they were laughed at. Even solutions already implemented in C were ignored. Pisses me off whenever I think about it. So the solution I have taken is: - use file_exists() and iterate over the include path setting - let users explicitly specify if they match an optional dependency - do not silence includes when the debug option is set Have a look at MDB2.php if you want to see how I did things. regards, Lukas