Bug #17731 Updated: [RFC+Patch] Handle parse errors in user-space
ID: 17731
Updated by: sniper@php.net
Reported By: jukkaho@mail.student.oulu.fi
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.2.1
New Comment:
Now that you've realized why this is not good idea, let's forget about
it then. :)
Previous Comments:
------------------------------------------------------------------------
[2002-06-13 03:58:27] jukkaho@mail.student.oulu.fi
Ok.. I think now that this is a relatively useless error handling since
I really can't capture other simple errors like calls to undefined
functions (E_ERROR) and if I try to comment that line out too, I just
get segfaults. :\
------------------------------------------------------------------------
[2002-06-12 16:46:51] jukkaho@mail.student.oulu.fi
In addition to include() -type functions, this seems to work extremely
well for eval() -statements too:
<?php
// error handler function
function myErrorHandler ($errno, $errstr, $errfile, $errline)
{
echo "Error: [$errno] $errstr ($errfile line $errline)<br><br>\n";
}
// set to the user defined error handler
$old_error_handler = set_error_handler("myErrorHandler");
// Try to evaluate some broken php
eval("echo \"Oops.. forgot the \\\"<br>;");
// Are we still here?
echo "Still here.<br>\n";
?>
I have seen some requests for that very often like
http://bugs.php.net/bug.php?id=13993 and they are
always just stopped
by saying that 'Parse errors are never handled by set_error_handler().'
------------------------------------------------------------------------
[2002-06-12 16:01:13] jukkaho@mail.student.oulu.fi
I (and apparently many others) needed functionality to handle errors in
include()d files.
I looked into it and by commenting a single line out in Zend/zend.c
this can be archieved with set_error_handler()
--- Zend/zend.c~ Wed Jun 12 22:35:11 2002
+++ Zend/zend.c Wed Jun 12 22:36:01 2002
@@ -682,7 +682,7 @@
zend_error_cb(type, error_filename, error_lineno, format, args);
} else switch (type) {
case E_ERROR:
- case E_PARSE:
+ /* case E_PARSE: User-space can handle this ok. */
case E_CORE_ERROR:
case E_CORE_WARNING:
case E_COMPILE_ERROR:
I have unsuccessfully tried to hang myself with this rope at the
moment.
Handler has to be installed before there are any parse errors. It just
won't work other way :). This means that it can't capture any errors in
main level but it can do it for any included file. This also means that
any errors in handler itself or code that installs it can't cause any
recursive loop.
I just can't figure out, how to break things with this (except maybe
some script which expect that no parse errors are sent to the handler)
Perhaps someone of you guys know a way to mess things up if I do this?
There's a comment a few lines below the patch point which says:
/* The error may not be safe to handle in user-space */
and forces zend_error_cb() to handle E_PARSE and other fatal errors.
Perhaps the comment is out of date since there is another comment at
the place where errors are actually handled:
/*case E_PARSE: the parser would return 1 (failure), we can bail out
nicely */
Other fatal errors (E_ERROR,E_COMPILE_ERROR,E_USER_ERROR) cause
zend_bailout() (I don't even know what this function does) etc. but
E_PARSE is handler like any warning or notice there.
So.. is this change safe? If not, what else need's to be changed? I
really like the functionality this tiny patch provides.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=17731&edit=1
Thread (4 messages)