php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #17731 [RFC+Patch] Handle parse errors in user-space
Submitted: 2002-06-12 16:01 UTC Modified: 2002-06-13 09:15 UTC
From: jukkaho at mail dot student dot oulu dot fi Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 4.2.1 OS: All
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jukkaho at mail dot student dot oulu dot fi
New email:
PHP Version: OS:

 

 [2002-06-12 16:01 UTC] jukkaho at mail dot student dot oulu dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-12 16:46 UTC] jukkaho at mail dot student dot oulu dot 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-13 03:58 UTC] jukkaho at mail dot student dot oulu dot 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-13 09:15 UTC] sniper@php.net
Now that you've realized why this is not good idea, let's forget about it then. :)


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC