Skip to content

[PropertyAccess] Do not silence TypeErrors from client code. #23100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 14, 2017
Merged

[PropertyAccess] Do not silence TypeErrors from client code. #23100

merged 1 commit into from
Jun 14, 2017

Conversation

tsufeki
Copy link
Contributor

@tsufeki tsufeki commented Jun 7, 2017

Q A
Branch? 3.2
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

Fixes TypeError silencing in setValue() when said error is thrown inside setter/adder/etc.

An example is given in the included test, but more real-life story is botched accessors for a many-to-one association on a Doctrine entity:

class B {
  function setA(A $a) { ... } // forgotten "= null" here
}

class A {
  function removeB(B $b) {
    if ($this->bs->contains($b)) {
      $this->bs->removeElement($b);
      $b->setA(null); // TypeError thrown
    }
    return $this;
  }
}

No error is shown to the user, even though removing doesn't work.

This bug is not present in 2.7 & 2.8.

@@ -244,6 +244,9 @@ public function setValue(&$objectOrArray, $propertyPath, $value)
}
} catch (\TypeError $e) {
self::throwInvalidArgumentException($e->getMessage(), $e->getTrace(), 0);

// It wasn't thrown in this class so rethrow it
throw $e;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't be this done in throwInvalidArgumentException instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, because it is used elsewhere too

Copy link
Member

@nicolas-grekas nicolas-grekas Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't the other place also throw?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the other place is error handler callback for PHP 5, there is no exception to rethrow, and errors are passed correctly to the original handler (here)

@nicolas-grekas nicolas-grekas added this to the 3.2 milestone Jun 9, 2017
@fabpot
Copy link
Member

fabpot commented Jun 14, 2017

Thank you @tsufeki.

@fabpot fabpot merged commit 45b961d into symfony:3.2 Jun 14, 2017
fabpot added a commit that referenced this pull request Jun 14, 2017
…e. (tsufeki)

This PR was merged into the 3.2 branch.

Discussion
----------

[PropertyAccess] Do not silence TypeErrors from client code.

| Q             | A
| ------------- | ---
| Branch?       | 3.2
| Bug fix?      | yes
| New feature?  | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks?    | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

Fixes TypeError silencing in `setValue()` when said error is thrown inside setter/adder/etc.

An example is given in the included test, but more real-life story is botched accessors for a many-to-one association on a Doctrine entity:

```php
class B {
  function setA(A $a) { ... } // forgotten "= null" here
}

class A {
  function removeB(B $b) {
    if ($this->bs->contains($b)) {
      $this->bs->removeElement($b);
      $b->setA(null); // TypeError thrown
    }
    return $this;
  }
}
```

No error is shown to the user, even though removing doesn't work.

This bug is not present in 2.7 & 2.8.

Commits
-------

45b961d [PropertyAccess] Do not silence TypeErrors from client code.
@tsufeki
Copy link
Contributor Author

tsufeki commented Jun 14, 2017

@fabpot I think @requires PHP 7.0 on the test got lost in the merge.

@fabpot
Copy link
Member

fabpot commented Jun 14, 2017

@tsufeki Indeed, not sure how it happened. Anyway, fixed in 8dc00bb. Thanks.

This was referenced Jul 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants