I'm not sure we need to work around since the new behavior has been reverted on <7.4
See#32395
For 7.4, there are more places that need to be changed, and I'd like we really understand the best way to fix the root issue.

Hmm, this is different and discussed inhttps://bugs.php.net/74372
@nikic can we consider fixing the BC break by having the new behavior only for child classes ofError and letException behave as before?

@nicolas-grekas I don't think introducing an Error/Exception distinction here makes sense. If you want to ignore exceptions, please ignore them explicitly.

We could revert from 7.3 and introduce in a later version, but given that we're at 7.3.8 already and this change is explicitly called out in the migration guide, I'm not sure doing that is a good idea. You'll have to deal with it at some point in either case...

@nikic thanks for the feedback, OK.

@fancywebI think the patch should be only this one:

--- a/src/Symfony/Component/Config/Resource/ClassExistenceResource.php+++ b/src/Symfony/Component/Config/Resource/ClassExistenceResource.php@@ -76,11 +76,12 @@ class ClassExistenceResource implements SelfCheckingResourceInterface, \Serializ              try {                 $exists = class_exists($this->resource) || interface_exists($this->resource, false) || trait_exists($this->resource, false);-            } catch (\ReflectionException $e) {+            } catch (\Throwable $e) {                 if (0 >= $timestamp) {                     unset(self::$existsCache[1][$this->resource]);                     throw $e;                 }+                $exists = class_exists($this->resource, false) || interface_exists($this->resource, false) || trait_exists($this->resource, false);             } finally {                 self::$autoloadedClass = $autoloadedClass;                 if (!--self::$autoloadLevel) {

The other places should not be changed (according to my current understanding at least.)

OK, I missed the} catch (\ReflectionException $e) { in warmers, I understand how the issue propagates here. We should factorize this logic now, inside throwOnRequiredClass I believe.

@nicolas-grekas Just pushed all tests + a deduplication of the code. I don't think it was what you wanted so I'm waiting for your feedback 😁

ClassExistenceResource::isFresh() is also affected + any direct user ofPhpArrayAdapter::throwOnRequiredClass() would too.
The plan could be:

• factorize inClassExistenceResource
• find a way to useClassExistenceResource instead ofPhpArrayAdapter inFrameworkBundle
• don't patchPhpArrayAdapter but deprecate itsthrowOnRequiredClass() in 4.4

@nicolas-grekas

factorize in ClassExistenceResource

Done.

find a way to use ClassExistenceResource instead of PhpArrayAdapter in FrameworkBundle

symfony/config is a requirement of theFrameworkBundle so it's alright.

don't patch PhpArrayAdapter but deprecate its throwOnRequiredClass() in 4.4

Actually this method was introduced directly as@internal, so I just removed it.

Thank you@fancyweb.