Edit report at http://bugs.php.net/bug.php?id=54033&edit=1

 ID:                 54033
 Comment 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
 Type:               Feature/Change Request
 Package:            Scripting Engine problem
 PHP Version:        5.3.5
 Block user comment: N
 Private report:     N

 New Comment:

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


Previous Comments:
------------------------------------------------------------------------
[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 http://bugs.php.net/bug.php?id=54033&edit=1

Reply via email to