Thanks for investigating this and creating a patch!

Commite35d6ba causes some odd behaviour. What seems to be happening is a that the requestStack->pop() in the original commit in the finally{} catch is being executed before the handleThrowable() is called.

I digged into this a bit more, as I don't like odd behavior 😃

What is important here is that the catch was only catchingException, notError. The one triggeringhandleThrowable() is a custom error handler. Apparently, if thetry { ... } block contains a PHP error, thefinally block is run before the error handler. I can reproduce this in a simple example:https://3v4l.org/mfgII

Unfortunately, I don't think we want to change the catch to\Exception|\Error like you did in this patch. This means the whole logic suddenly gets errors as well, instead of exceptions. That seems like a big BC break to me.

However, I'm unsure what to do here. To me, it seems like we should reverte35d6ba and find a way to somehow pop the request stack for errors as well, without finally block. Let's see if some of the PHP experts in the core team have a good suggestion here :)

Hey@wouterj yeah, that's precisely the issue. I wondered the same thing about the Throwable vs Exception. Glad for someone else to weigh in on this. One thing I'd note is that with my patch, I get what I would consider 'expected' behaviour. I get the normal symfony exception page with the stack trace etc

Should be fixed by#47857