sentry-symfony: Overriding error handler changes symfony error handler
When using older version of Sentry (v2) with Symfony (v5.2) the handler in DebugHandlersListener::configure() is
$handler = {array} [2]
0 = {Symfony\Component\ErrorHandler\ErrorHandler} [18]
1 = "handleException"
in Sentry v3 the ExceptionListenerIntegration overrides exception handler in registerOnceExceptionHandler() via line
self::$handlerInstance->previousExceptionHandler = set_exception_handler(\Closure::fromCallable([self::$handlerInstance, 'handleException']));
therefore the handler is now of type Closure, not array
And the condition in Symfony’s DebugHandlersListener is not satisfied
$handler = set_exception_handler('var_dump');
$handler = \is_array($handler) ? $handler[0] : null;
restore_exception_handler();
$handler is now null.
That kind of significantly influences the rest of app behaviour.
TBH I don’t know what is the proper solution to the problem. Is it intended? I wish to keep Symfony error handler as I hook into its events.
Setting $handler to null forces symfony/debug’s ErrorHandler to be used instead and I don’t want that, it does not use onKernelException() listeners for example.
(
- Upgrading sentry/sentry (2.5.0 => 3.1.2): Extracting archive
- Upgrading sentry/sdk (2.2.0 => 3.1.0)
- Upgrading sentry/sentry-symfony (3.5.2 => dev-master f34ebf2): Extracting archive
)
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 2
- Comments: 17 (2 by maintainers)
I experienced the same issue on our Symfony apps.
There is nothing special to do to reproduce: the issue is that when
Sentry\Clientis instantiated, it mutates the global state by setting its own error/exception handler.When running tests, this leads to a red warning that says
THE ERROR HANDLER HAS CHANGED!, because the phpunit-bridge detects that the tests end with a different error handler than the one they started with.This could be fixed by making Sentry not set its error handler when no DSN is defined. Do you think that’s doable?
Then there is this in
DebugHandlersListener: we read the error handler stack to get access to the current error handler. If we find Symfony’s there, then we configure it. But since Sentry replaces it with its own, the listener does nothing, and the app is not fully configured.Honestly, I don’t get why Sentry would hook as an error handler: in the context of Symfony, we already have logs to report PHP warnings/etc. Can’t this be removed?
I might also try to find another way to get access to our error handler so that we can still configure it when another piece of code replaces it.
Is there maybe a work-around for this? 🙂 We are still using Sentry v2 and we would like to update our Sentry integration to Sentry v3 for ie. PHP8.1 support. However, not having all
\Errors in our other logging/monitoring systems is a problem for us.🦚
Not sure about this… @nicolas-grekas, could you help us out here? Does the Symfony error handler NOT support closures as handlers?