One reason I use set_error_handler() is to catch possible security problems... if a cracker/hacker is trying to gain access to my site, one thing he might do is try to change the code.... now, if I was trying to hack into a site by changing the code, the first thing I would do would do is cause parse errors!

The security issues I can see, of not allowing set_error_handler() to catch parse errors are:

	Informing a attacker when he has done something wrong so he can correct it!
	Giving information that php is powering the web site (by the error message)!
	Giving away sensitive information such as, what line he caused the error on!
	And most of all, not allowing the webmaster deal with a parse error cracker!

If a parse error is caused on a page that I have checked over, and know there are no parse errors on, the chances of a hacker/cracker are very good. In fact if a parse error is caused, I would like to be notified by email, (just like all the other errors) and I would like to deactivate the user (if any) that the intruder is logged in to. A third precaution, would be to try to ban the hacker/cracker computer from viewing any of my pages.

Adding support for pares errors with set_error_handling would also help to solve the rare cases where a parse error may actually exist on one of your pages. A more likely situation is where php builds pages according to user data. This would dramatically increase the changes of a parse error.

All in all, I think adding support for this would far outweigh the time it takes to implement it.

Thanks for listing,

Brendan