Re: set_error_handler and set_exception_handler behavior

From: Date: Tue, 27 Mar 2012 13:44:04 +0000
Subject: Re: set_error_handler and set_exception_handler behavior
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-59183@lists.php.net to get a copy of this message
On Sat, Mar 24, 2012 at 8:29 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > I don't think ability to reset handlers by passing null is a big > problem, and creating another four functions seems excessive to me. > Also, the use case for the latter ones is not clear - why would you need > old error handler if you are not changing it? If you are changing it, > the case for getting the old one is clear - you may want to restore it > later. But if you're not, why you'd need it? Agree. > As for returning true on null, I see no sense if this behavior. Can > anybody explain to me what is it useful for? Why not return old handler > just as it is done in all other cases of setting the handler? Agree. >> What I would do: >>  Add support for set_error_handler(NULL) and change the return value >> of set_error_handler(NULL)+set_exception_handler(NULL) to the previous >> handler (i.e. Stas option). I implemented this option in this PR: >> https://github.com/php/php-src/pull/20 > > I think this makes sense (of course, since it's my proposal :). It is a > behavior change, so it should be confined to master branch. Not sure about that part. I think both changes should be considered as bug fixes and as such should also be eligible for 5.3/5.4. The set_error_handler(null) change has no impact on BC whatsoever and the return value change only has a theoretical BC impact (why would you check the return value if it is *always* true?) Nikita

« previous php.internals (#59183) next »