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:
Thanks Jon. Imho, your suggestions are practical ways to accomplish my
prior notion, "...why can't the set_handler_error input function be
parsed separately and run in a separate process?...".
Too bad the PHP developers closed this bug prematurely. Any one else
who wants to contribute to this bug report, just email me and I will
post your comments to this bug report if warranted.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2006-07-25 23:57:21] shelby at coolpage dot com
From: "Jon Meyer" <jonmeyer at gmail dot com>
Subject: error reporting in PHP
Date: Tue, July 25, 2006 7:38 pm
To: shelby at coolpage dot com
--------------------------------------------------------------------------------
I saw your bug 38184, but its closed so I can't comment on it there.
My thought was that you could propose an alternative mechanism for
doing what you want (encoding error responses in JSON):
What if there was a
set_fatal_error_redirect('error.php');
For fatal errors, instead of trying to continue evaluating the current
request (engine may be in an unstable state etc) the PHP engine could
collect the output it was going to print to the client, create a new
evaluation context and then evaluate the contents of the error.php
essentially as if it were a new request - passing the error output in
as the value of a global variable e.g. $_SERVER['error']That way you
could write an error.php like:
<?php
function jsonEncode($str) { ... }
print "{"error":\"" . jsonEncode($_SERVER['error']) . "\"}";
?>
I've seen other servers which handle errors using the "redirect"
concept - it may fly better than trying to fix set_error_handler.
Jon
------------------------------------------------------------------------
[2006-07-23 12:54:23] shelby at coolpage dot com
"...instead of spending your time with this monologue..."
So reporting bugs to you is a waste of our time?
We should stop reporting bugs?
100% nonsense.
------------------------------------------------------------------------
[2006-07-23 12:49:28] shelby at coolpage dot com
"...Why don't you just disable display_errors..."
How many times do I have to repeat what I already wrote, "...or it can
cause the reporting error to be not
reported...other than to turn off error reporting..."
The point is that this bug effectively causes error reporting to not
occur for JSON (or other Content-Types) output. Whether that is
accomplished via corrupted output or via error_reporting( 0 ) is
besides the point.
The point being that without error reporting, users of the application
will get silent failure. That is why error reporting exists in the
first place. Error reporting is a fundamental aspect of robust
programming.
Your fix to a bug is mark it as "Won't Fix", tell the programmer to
turn off error reporting, and the accuse the bug reporter of typing a
"monologue"??
Wonderful.
------------------------------------------------------------------------
[2006-07-23 09:49:25] [EMAIL PROTECTED]
Why don't you just disable display_errors instead of spending your time
with this monologue?
------------------------------------------------------------------------
[2006-07-23 09:00:59] shelby at coolpage dot com
"...we prefer to get a nice error message instead..."
The nice error message ends up in corrupted output that the client does
not understand and thus can not display, thus that nice error is lost
and program can not be fixed, because user is unable to report the
error to programmers.
In short, the application just fails silently with a Javascript error
in the client.
I think you need to take some more time to understand the problem,
before jumping to "Won't Fix".
------------------------------------------------------------------------
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
