Edit report at https://bugs.php.net/bug.php?id=54033&edit=1
ID: 54033 User updated by: tyra3l at gmail dot com Reported by: tyra3l at gmail dot com Summary: add get_error_handler and get_exception handler -Status: Re-Opened +Status: Closed Type: Feature/Change Request Package: Scripting Engine problem PHP Version: 5.3.5 Block user comment: N Private report: N New Comment: test Previous Comments: ------------------------------------------------------------------------ [2011-02-18 11:45:20] tyra3l at gmail dot com the get_exception_handler is least important for me: I cannot come up with a situation, which couldn't be solved by set_exception_handler and restore_exception_handler, because the exception handler doesn't have something like the $error_types in the set_error_handler. but I think it would be more consistent if both the error and exception handler functions would provide that. Tyrael ------------------------------------------------------------------------ [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael ------------------------------------------------------------------------ [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. ------------------------------------------------------------------------ [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 https://bugs.php.net/bug.php?id=54033&edit=1
