Edit report at http://bugs.php.net/bug.php?id=54033&edit=1
ID: 54033
Updated by: rasmus@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