On Sat, Mar 24, 2012 at 8:29 PM, Stas Malyshev <smalys...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
