Re: Silenced include(_once) calls

Justin Patrin wrote:

<snip> 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. 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. 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. -- Justin Patrin There was a discussion on QA, "Silencing @" started on 2005/10/31 , on this subject and more generally uses of @.

Unfortunately seems the mailing list archive "swallowed" all the messages during few days in this period (2005/10/22 up to 2005/11/10) I suggested there another solution for require_once: In fact, the goal is to prevent only a WARNING, $current = error_reporting(); error_reporting($current & ~E_WARNING);

require_once 'there/option.php';    // no more @

error_reporting($current); That's naturally still not perfect as here, any other potential warnings will be silenced ... But a lesser bad. I believe the @open() method is certainly the best solution, should not give much overload. That said, I also consider that is to be used only where something really optionnal exists. After all, taking the example of Text_Wiki, if some implementer does: $wiki = & factory('BBCode'); but s?he did not install the Text_Wiki_BBCode extension, I see no problem to let PHP kill the stuff. The error messages will be quite explicit. Regards -- toggg