ID: 38184 User updated by: shelby at coolpage dot com Reported By: shelby at coolpage dot com Status: Wont fix Bug Type: Output Control Operating System: Irrelevant PHP Version: 4.4.2 New Comment:
"...we don't want the engine to crash..." By the time the script has been terminated by an error, it logically already has effectively crashed. Each script runs in it's own process, so if the engine crashes for a script while processing user error reporting code, only that process of the engine crashes, thus effectively this is the same as the script ending. Thus my logic 101 applies. "...NO catch/try blocks in 4.4.2..." There are in PHP5. Are we trying to go backwards or get a solution? "...E_FATAL/E_ERROR errors are completely different from exceptions..." I repeat: "Even if we are talking about parsing errors (script is not yet executing), why can't the set_handler_error input function be parsed separately and run in a separate process?" "...We would gladly review your patches..." a) Then why is this bug marked "Won't Fix"? b) Why not just say "don't report bugs to us that we don't want to hear about"? c) Miraculously "Won't Fix" bugs fall into a blackhole and are not displayed on your stats page, so public is unaware of how many bugs you won't fix: http://bugs.php.net/bugstats.php Previous Comments: ------------------------------------------------------------------------ [2006-07-23 07:59:09] [EMAIL PROTECTED] >Then how do you explain the existence of catch{} recovery > after try{} blocks? First of all, there are NO catch/try blocks in 4.4.2 (and this is the version you specified). Second, try/catch block never did catch any errors at all, they are for exceptions only. Third, E_FATAL/E_ERROR errors are completely different from exceptions and no wonder engines state is different too. >Thus logic 101 says that #B is superior. My logic says that we don't want the engine to crash and we prefer to get a nice error message instead in case if your code is completely wrong and is not going to work. >Sounds to me the bug is something that you (the person > changing this to "Won'd Fix") doesn't want to work on, > versus being something impossible to fix? We would gladly review your patches. ------------------------------------------------------------------------ [2006-07-23 07:26:33] shelby at coolpage dot com Are you referring to Zeev's comments in bug #12136, that the engine may be unstable after certain errors? Then how do you explain the existence of catch{} recovery after try{} blocks? How is the engine able to be stable enough to run user code in the catch{} block? Even if we are talking about parsing errors (script is not yet executing), why can't the set_handler_error input function be parsed separately and run in a separate process? Now back to logic 101: (A) Let's assume the PHP/Zend engine can not be made stable after E_ERROR type errors, so the result for the case of this bug is "no error reporting" (of E_ERROR type errors) and unexplained crash of script. (B) Whereas if we enabled set_error_handler to capture E_ERROR, then in cases where the engine was not too unstable, the error would get reported and the script would die with explanation reported. In cases where engine was too unstable and set_error_handler crashed, then we still get the result of #A. Thus logic 101 says that #B is superior. Sounds to me the bug is something that you (the person changing this to "Won'd Fix") doesn't want to work on, versus being something impossible to fix? ------------------------------------------------------------------------ [2006-07-23 07:08:55] [EMAIL PROTECTED] Zeev gave pretty good explanation why it won't happen. ------------------------------------------------------------------------ [2006-07-23 06:45:34] shelby at coolpage dot com Even applying full JSON parsing (or any "Content-Type" parsing) will not workaround the problem, because if the error occurs in the middle of the content, the client will be unable to extract the error message and present it. Thus error reporting is effectively off. That is why I say the only generalized workaround is to turn off error reporting. Thus it is a bug that turns off error reporting in generalized case. How is turning off error reporting less reliable than allowing set_error_handler to attempt process all error type (even if engine has become unstable)? The generalized fix would be to fix the engine so that it is not rendered unstable by errors. One would think you already have achieved such, given the existence of try-catch error trapping. Seems the limitation placed on set_error_handler is now unnecessary? ------------------------------------------------------------------------ [2006-07-23 06:37:12] shelby at coolpage dot com Someone changed this bug to to Feature Change Request. I have changed it back to Output Control bug, because currently there is no way to prevent error_reporting from outputting content which violates (a BUG) the header( "Content-Type..." ) of the script (when it is not "text/html"), except to turn error_reporting off. Sorry to say, this is a bug, as it can cause the client web app to function incorrectly, or it can cause the reporting error to be not reported. There is no generalized workaround possible (if the error is generated in middle of non-"text/html" content), other than to turn off error reporting. How could you not define this as a bug? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38184 -- Edit this bug report at http://bugs.php.net/?id=38184&edit=1
