|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #54033 add get_error_handler and get_exception handler
Submitted: 2011-02-17 00:44 UTC Modified: 2017-10-24 08:14 UTC
Avg. Score:4.5 ± 0.7
Reproduced:11 of 11 (100.0%)
Same Version:5 (45.5%)
Same OS:2 (18.2%)
From: tyra3l at gmail dot com Assigned:
Status: Open Package: Scripting Engine problem
PHP Version: 7.0 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: tyra3l at gmail dot com
New email:
PHP Version: OS:


 [2011-02-17 00:44 UTC] tyra3l at gmail dot com
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 

I mentioned this on twitter (I wasn't really nice)!/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)


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-17 00:50 UTC]
-Status: Open +Status: Bogus
 [2011-02-17 00:50 UTC]
set_error_handler() already returns the previously set error handler, if any.
 [2011-02-17 01:04 UTC] tyra3l at gmail dot com
of course it returns the callback.
- 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.

 [2011-02-17 01:41 UTC]
-Status: Bogus +Status: Re-Opened
 [2011-02-18 11:45 UTC] 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.

 [2012-03-18 16:41 UTC] tyra3l at gmail dot com
 [2012-03-18 16:41 UTC] tyra3l at gmail dot com
-Status: Re-Opened +Status: Closed
 [2012-03-18 16:41 UTC] tyra3l at gmail dot com
 [2012-03-18 16:41 UTC] tyra3l at gmail dot com
-Status: Closed +Status: Assigned
 [2012-03-18 16:46 UTC]
-Status: Assigned +Status: Open
 [2012-03-18 16:46 UTC]
sorry for my last two changes about this issue.
 [2012-08-25 14:16 UTC] matthew dot bonner at gmail dot com
I'm not sure the focus was of the exception handler and the reason I bring this up is you have mentioned about restoring the exception handler, however I think this bug applies to exceptions as well.

I think for security alone, you should be able to call get_error_handler as if a rogue script has overridden the error handler you have no way of knowing without changing the error handler.

Because there is no get_error_handler() you have to type:
function tempErrorHandler () {}
$previousErrorHandler = set_error_handler('tempErrorHandler');

Even worse, people are probably writing a function called get_error_handler() to do this because you haven't provided this functionality. This means when you come to implement something like this you will have to provide enough time for people to remove their own implementation of this function.

Another issue is how to restore the original PHP error handler, take for instance the following scenario:
function tempErrorHandler () {}
function basicErrorHandler () {}

Calling restore_error_handler() restores the tempErrorHandler, that's great, we now have an error handler that is doing nothing.

Please seriously reconsider your stance on the functionality provided for both the error and exception handling.
 [2012-08-25 14:23 UTC] matthew dot bonner at gmail dot com
I would like to add that I'm aware PHP stacks up the error handlers, so calling restore_error_handler over and over will eventually restore the original error handler but this isn't possible unless you do something like:

to make sure that you have fully restored the PHP error handler as there is no way of knowing which error handler is in use!

This is so frustrating as I use PHP commercially to write software for banks, councils and various other large enterprises where the software mutates itself and forks new instances of itself which means the error handling is changed and requires changing back, but if at some point in the script the error handler has been changed by something else we have no way of knowing just how many times we need to call restore_error_handler before we are back with the error handler we need.

I'm hoping it is clear now why we need a get_error_handler() and get_exception_handler().
 [2012-08-25 14:42 UTC] matthew dot bonner at gmail dot com
For anyone else who finds the implementation of the error handling functions a bug, the following might help:
function void_error_handler () {}

function get_error_handler () {
  $error_handler = set_error_handler('void_error_handler');
  return $error_handler;

function restore_php_error_handler () {
  while (set_error_handler('void_error_handler') !== NULL) {

This is what we have to resort to, stop not admitting this is a bug when it is!
 [2014-12-30 18:37 UTC]
-PHP Version: 5.3.5 +PHP Version: 7.0 -Assigned To: +Assigned To: tyrael
 [2014-12-30 18:38 UTC]
I've created a PR for these functions targetting master(aka PHP7), let see what others think about merging it.
 [2017-10-24 08:14 UTC]
-Status: Assigned +Status: Open -Assigned To: tyrael +Assigned To:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 13 04:01:28 2024 UTC