From: [EMAIL PROTECTED]
Operating system: n/a
PHP version: 4.2.2
PHP Bug Type: Feature/Change Request
Bug description: custom handlers for parse errors
I'd love to see a mechanism in PHP similar to the Apache ErrorDocument
directive to allow the custom handling of pre-execute-time errors (such as
most parse errors), since these errors precede and thus usurp
set_error_handler(), leaving you otherwise stuck with only slightly
modifiable PHP error messages.
The error values error_type_str, buffer, error_filename, error_lineno, and
type (from main/main.c) could be passed to the handler script as
$_SERVER["error_type_str"], et. al. to allow the handler to use them
dynamically - perhaps even passing them to the same custom error handler
function that got spurned the first time around, i.e.:
------------------------------------
<?php
// /bad_script.php
include_once("my_function_lib.inc");
// contains valid function my_custom_error_handler()
set_error_handler("my_custom_error_handler");
// and would all be fine and good to catch errors such as:
$x=1/0;
// except
xxxxx
xxxxx
// causes a parse error, which gets processed before
// my_custom_error_handler() is available
exit;
?>
------------------------------------
# php.ini or .htaccess
# (... other directives)
php_error_document = '/error_handler_script.php'
# (other directives ...)
------------------------------------
<?php
// /error_handler_script.php - to the rescue
include_once("my_function_lib.inc");
// same as above, but now we
my_custom_error_handler($_SERVER["error_type"],
$_SERVER["error_type_str"],
$_SERVER["error_filename"],
$_SERVER["error_lineno"]);
// to do directly what we were unable to do via
// set_error_handler() the first time around
exit;
?>
------------------------------------
I've seen a few posts from people looking for something like this, and
this strikes me as the most elegant way of going about it. I've also read
replies to similar posts and I don't see this particular approach having
been suggested before. As to "(t)he (php-dev) decision ... that parse
errors are preventable" - I definitely agree, and will add that they're
easier to prevent as it gets easier to find and fix them. That's what this
idea is trying to accomplish - I want my error handler on my development
server to display the source code at and around the error so that I can
more quickly find and fix the problem.
Looking at the PHP source I'm guessing it wouldn't be terribly difficult
to implement this... you'd just need to make sure you break out of the
loop that would otherwise be caused if the error handler script itself has
a parse error in it...
I'm using 4.2.2 but I noticed that your change log as of 4.3.0 doesn't
mention anything like this, so I assume I'm not re-proposing the wheel
here.
Thanks.
--
Edit bug report at http://bugs.php.net/?id=21759&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21759&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21759&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21759&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21759&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21759&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=21759&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21759&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=21759&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=21759&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21759&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21759&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21759&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21759&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=21759&r=gnused
