For a getter method I would not expect the method to modify the object's state but to be able to call the method several times with the same result.

I'll name thisresetExceptions()

Now it's not really clear that I could use this method retrieve the list of all caught exceptions. What about adapting the schema used for methods in the SPL and use something likeshiftAll()?

This depreciation message is not actionable. It should tell to passtrue as last argument to get rid of it.

Although this would still not be the right fix in the framework context, since thecatch_all_throwables option needs to be set totrue.
Maybe the configuration needs a->validate() node to trigger onfalse with the "good" message.

I've updated the exception message.

Maybe the configuration needs a ->validate() node to trigger on false with the "good" message.

Hm.. Yeah. But isn't that overkill?

I can see two paths. Once you get rid of the deprecation you should be ready for 7.0, but in this case it means passingtrue instead offalse.

• Removing the argument and the config node could be done in 8.0, once first deprecated in 7.1.

• However removing the arg as it seems to be expected in 7.0 won't break, but will make passing the arg some dead code without notice. Also removing the config node in 7.0 would be a BC break if devs continue to define it totrue.

Since the constructor argument and config is part of the deprecation layer they will both be removed in 7.0.
Aren't we overthinking now?

choices_as_values option was used for Symfony 2 deprecation layer, but deprecated in 3.1,
logout_on_user_change option was used in Symfony 3 deprecation layer and deprecated in 4.1 and so on.

The BC should be to not change your code when upgrading to 7.0, in this case changingfalse totrue would make it work, but once done, another change would be required to remove config and arg, so they must still exist before we can safely remove them.

In other words, the deprecation layer itself cannot be deprecated in 6.x nor removed in 7.0, it needs to be deprecated in 7.1.

Maybe the configuration needs a ->validate() node to trigger on false with the "good" message.

Hm... Yeah. But isn't that overkill?

Well, the problem I see is that most devs using the framework do not even know there is anHttpKernel service nor how to change this arg.
However, mentioning the config key in this message from the component feels wrong.