Edit report at http://bugs.php.net/bug.php?id=54033&edit=1
ID: 54033 Updated by: ras...@php.net Reported by: tyra3l at gmail dot com Summary: add get_error_handler and get_exception handler -Status: Open +Status: Bogus Type: Feature/Change Request Package: Scripting Engine problem PHP Version: 5.3.5 Block user comment: N Private report: N New Comment: set_error_handler() already returns the previously set error handler, if any. Previous Comments: ------------------------------------------------------------------------ [2011-02-17 00:44:58] tyra3l at gmail dot com Description: ------------ my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=54033&edit=1