- Issue created by @berdir
- 🇨🇭Switzerland berdir Switzerland
Turns out that core does on fact have one example that relies on the exception being thrown.
- 🇺🇸United States smustgrave
But good news is that the functional test was random.
There is an attempt to remove magic access for fields on content entities 📌 [meta] Deprecate __get/__set() on ContentEntityBase Postponed
One concern mentioned there is that $entity->get('field_name') throws an exception, while $entity->field_name does not.
This results in pretty unwieldy code:
if ($entity->hasField('field_name') && $entity->get('field_name')->value)
This made sense many years ago when it was added, but since then we have nullable operator, so if we remove the exception, we can do this:
if ($entity->get('field_name')?->value)
Remove the exception.
Per my comment in the meta issue, there is one problem with this:
The only problem I see is someone is relying on the exception and is catching that, then it would result in a php warning or something instead. like this:
Unsure how to approach that:
1. We could ignore that, and that code will just need to be be adjusted. I hope people haven't done that a lot :)
2. We trigger a deprecation before throwing the exception and remove it in D12. Somewhat unlikely that code doing that will actually see that deprecation, but it gives it a chance and time to adjust.
Active
11.1 🔥
entity system
Turns out that core does on fact have one example that relies on the exception being thrown.
But good news is that the functional test was random.