Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
fd71093 tocfe490dCompareThere 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
stof commentedSep 26, 2014
|
cfe490d toae6c88dComparewebmozart commentedSep 26, 2014
@stof done |
shoomyth commentedSep 26, 2014
What do you think about deprecating |
webmozart commentedSep 26, 2014
@shoomyth |
webmozart commentedSep 30, 2014
ping @symfony/deciders I'd like to merge this PR today. |
fabpot commentedSep 30, 2014
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. |
stof commentedSep 30, 2014
@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. |
webmozart commentedSep 30, 2014
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 tocd4b3f8Compare…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 | TODOThis 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.```phptry { // ...} 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 violationcd4b3f8 to8dbe258Compare…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.