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:
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?
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2006-07-22 12:04:03] shelby at coolpage dot com
Obviously the workaround does nothing for the case where the "{" has
already been output (or if PHP decides to output "{" as first char of
it's errors), and then PHP generates an HTML error into the middle of
the JSON output.
I guess the more reliable client side workaround should use a full JSON
parser.
------------------------------------------------------------------------
[2006-07-22 12:00:25] shelby at coolpage dot com
Detecting the "Content-Type" with XMLHttpRequest::getResponseHeader()
is not a workaround, because PHP's built-in error output does not
override the header( "Content-type: application/json" ) set by the PHP
script.
So the workaround gets even more bizzare, with the client having to
parse the XMLHttpRequest::responseText for JSON syntax errors to
determine it isn't JSON. <sarcastic>What a wonderfully reliable form
of error reporting</sarcastic>!
For now my workaround is I make sure the 1st char of JSON server-side
output is "{", then client side I do
XMLHttpRequest::responseText.chatAt( 0 ) != "{" to detect that a PHP
error has been received instead of JSON.
Correct typo: I meant XMLHttpRequest, not XHttpRequest.
------------------------------------------------------------------------
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
