Debug handler bails early and no error page is shown

[Jean85]

Symfony version(s) affected: 4.1.6 (and probably earlier) [edit] confirmed up to 4.2.4

Description
When registering an additional error handler, in prod environment no error page is shown, even if correctly registered through the TwigBundle.

How to reproduce
This stems from getsentry/sentry-symfony#63, where @PapyDanone created a small reproduced of the issue here: https://github.com/PapyDanone/sentry-blank-page

I've tried to debug it but it's pretty hard, due to the fact that the issue seems to be in multiple registered error handlers. From what I've observed, the ErrorHandler frees some memory here, and afterward calls the fatal handler, which bails early here.

All of this is done without calling the Twig's exception listener which should call the setResponse and show the custom error page. Since the behavior is commented, it's intentional, but I do not understand why Twig is not called in this case.

Additional context
Sentry error handler is registered here if you're interested, but it shouldn't matter: https://github.com/getsentry/sentry-php/blob/c266b71c031d3195ac3be5b9f442865753624799/lib/Raven/Client.php#L262-L277

[starred-gijs]

I think this is fixed by #30264

[PapyDanone]

I updated my reproducer: https://github.com/PapyDanone/sentry-blank-page, and I'm still seeing the issue with the syntax error introduced in DefaultController.

On Sentry, the error gets correctly reported:

Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: syntax error, unexpected 'Class' (T_CLASS) in /Users/redacted/Sites/sentry-bug/src/Controller/DefaultController.php:15

[starred-gijs]

Yes you are correct. I was testing it as we speak in a production-like env and it fixed the situation where I throw an exception in the onKernelException event, but not actual syntax errors.

ps. Throwing an exception in onKernelException was a bit of weird solution anyway, so that is now replaced with $event->setException(...

[Jean85]

Thanks @PapyDanone for testing this thoroughly.

He reported that even with the new major version of the Sentry bundle (which is based on a nearly complete rewrite of the SDK) we still have this issue: getsentry/sentry-symfony#63 (comment)

[Simperfit]

@Jean85 Do you want to work on it ?

[Jean85]

I'm not sure if I have other time to dedicate, I tried debugging it a bit but I couldn't find the root cause.

[carsonbot]

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

[carsonbot]

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

[carsonbot]

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!