On Sat, Mar 24, 2012 at 8:29 PM, Stas Malyshev 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 n
Hi!
> What people objected to:
> * Stas: The bool(true) return value does not really make sense.
> Instead the previous error/exception handler should be returned, as
> always.
> * Pierre: One shouldn't be able to reset the error/exception handler
> like that in any case. This behavior should be
On Sat, Mar 24, 2012 at 9:26 PM, Nikita Popov wrote:
> Hi internals!
>
> Laruence and myself yesterday tried to slightly modify the
> set_error_handler behavior, but the change which we considered trivial
> was not perceived as such by others. So we are taking this to the ML.
>
> Current state of
Hi internals!
Laruence and myself yesterday tried to slightly modify the
set_error_handler behavior, but the change which we considered trivial
was not perceived as such by others. So we are taking this to the ML.
Current state of things:
* set_error_handler(callback) and set_exception_handler(c
Jason Garber wrote:
Don't forget that some users make use of set_error_handler(). This
Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it you
end up calling the user error handler *lots* even if you disabl
