|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2010-12-20 15:49 UTC] jani@php.net
-Package: Feature/Change Request
+Package: Scripting Engine problem
[2015-08-28 17:18 UTC] nikic@php.net
-Status: Open
+Status: Closed
-Assigned To:
+Assigned To: nikic
[2015-08-28 17:18 UTC] nikic@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 29 17:00:02 2025 UTC |
Description: ------------ The troublesome scenario: Using a central __autoload() function to load all classes of the application (wich uses libraries that uses different file extensions): function __autoload($classname) { @include($classname.'.php'); if(class_exits($classname)) return; @include($classname.'.class.php'); if(class_exits($classname)) return; die("$classname not found"); } Now, it is terrible to debug applications that use this scheme. The @ operator supress fatal error messages. I don't belive there is a point for this behavior. If one doesn't want error messages, simply turn of the global error_reporting option. Why expect a blank page for one or two commands when something goes wrong? Request #1: It would be desirable to have the @ operator not supressing fatal error messages. Now, in the __autoload() context, the user error handler (setted with set_error_handler()) is not used, if we remove the @ from include() statements. The warning messages are sent to the default error handler (therefore, to the output if display_errors is on). Request #2: __autoload() should respect the current error handler settings. Related reports I've found: #8294 #32545