-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] The trace of form errors is now displayed in the profiler #12054
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
Conversation
fd71093
to
cfe490d
Compare
@@ -14,6 +14,8 @@ CHANGELOG | |||
* deprecated `ClassMetadata::addMemberMetadata()` | |||
* [BC BREAK] added `Mapping\MetadataInterface::getConstraints()` | |||
* added generic "payload" option to all constraints for attaching domain-specific data | |||
* [BC BREAK] added `ConstraintViolationBuilderInterface::setCause()` | |||
* [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks weird
|
cfe490d
to
ae6c88d
Compare
@stof done |
What do you think about deprecating |
@shoomyth |
ping @symfony/deciders I'd like to merge this PR today. |
My only concern is the "yet another BC break in the Form component". I think that having interfaces that change in every single Symfony version do not help. Not having those interfaces in the first place would be in fact better. |
@fabpot we have 2 implementations of the interface in core. And removing it would force breaking BC in all form types (as they typehint the FormInterface in But the interface is meant for consuming it in userland, not for implementing it. I doubt anyone is crazy enough to reimplement the FormInterface in a different way in their project, and only these crazy people would be affected by this BC break. |
Exactly. People are supposed to type-hint against the interface, not implement it. Our benefit is the flexibility to pass any implementation of the interface that we like, be it |
81b4121
to
cd4b3f8
Compare
…onstraint violation (webmozart) This PR was merged into the 2.6-dev branch. Discussion ---------- [Validator] Made it possible to store the cause of a constraint violation | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | yes | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | TODO This change makes it possible to store the cause of a violation (e.g. an exception). This way it is possible to follow the trace of violations caused by exceptions up to their root. ```php try { // ... } catch (Exception $e) { $this->context->buildViolation('Error!') ->setCause($e) ->addViolation(); } ``` This is one step to solve #5607. See #12054. Commits ------- 499eeb4 [Validator] Made it possible to store the cause of a constraint violation
cd4b3f8
to
8dbe258
Compare
…e profiler (webmozart) This PR was merged into the 2.6-dev branch. Discussion ---------- [Form] The trace of form errors is now displayed in the profiler | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | yes | Deprecations? | no | Tests pass? | yes | Fixed tickets | #5607 | License | MIT | Doc PR | - This is a follow-up PR for #12052. With this change, the full trace of form errors is now displayed in the web debugger:  If a violation was caused by a TransformationFailedException, the exception is now accessible through the `getCause()` method of the violation. Additionally, you can access `Form::getTransformationFailure()` to retrieve the exception. Commits ------- 8dbe258 [Form] The trace of form errors is now displayed in the profiler
This is a follow-up PR for #12052. With this change, the full trace of form errors is now displayed in the web debugger:
If a violation was caused by a TransformationFailedException, the exception is now accessible through the
getCause()
method of the violation. Additionally, you can accessForm::getTransformationFailure()
to retrieve the exception.