Edit report at https://bugs.php.dev/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: Closed
+Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:5.3.5
Assigned To:tyrael
Block user comment: N
Private report: N
New Comment:
hi
Previous Comments:
[2012-03-18 17:52:10] tyr...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[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.dev/bug.php?id=54033&edit=1