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.