I believe you can use RETURN_COPY instead of RETURN_ZVAL because those handlers can't be references, so the generated code will be a bit shorter by using RETURN_COPY then.

Does it make sense to add two test cases?

1. get_error_handler() == get_error_handler()
2. Invoking get_error_handler() without prior change of error handler.

And the same for get_exception_handler()

@Girgias

I wonder however if as a follow-up we should refactor how the error/exceptions handlers are stored (e.g. as an FCC instead of a zval) so that we can return a Closure that is guaranteed to always be valid

Unfortunately I can not change that because the behaviour is specified explicitly in the RFC: "The returned handler is the exact callback value that was passed to set_error_handler() or set_exception_handler() to define it". It's useful, as this makes it possible to inspect the error handler and to compare it against known values. There are some examples here, here, or here.

Is the scope the only issue making the value potentially not callable? An alternative solution to that problem may be to change set_error_handler so that it accepts only callables that are valid in any scope.

Currently, set_error_handler accepts anything that's callable from the current scope, but zend_error_zstr_at() may fail to call the handler later, from a different scope.

Any plans adding also get_shutdown_handlers?

@janedbal I didn't plan to. Do you have example use cases?

Thanks everyone for the reviews!

Do you have example use cases?

Yes. We built a tool that tries to detect "memory leaks" by scanning all global space (static vars, closure uses, ...). One of the few places that is currently not accessible at all are shutdown handlers.

For reference, here is some initial version of that.

This makes sense, thanks! I'm adding this on my TODO (but if anyone wants to take care of this, feel free).