[Validator] catch any UnexpectedValueException on validation #27917

xabbuh · 2018-07-10T13:51:47Z

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

xabbuh · 2018-07-10T13:54:16Z

This change would fix issues like #14943 (and many other related issues). I didn't add any tests yet, but would like to get some feedback first as setting them up seems to be quite complex. I am not sure if anyone could have actually relied on the previous behaviour. If we think that this was a supported use case, we will probably have to make this feature opt-in.

ro0NL · 2018-07-10T13:56:54Z

Shouldnt we, for consistency, raise a violation per case:

symfony/src/Symfony/Component/Validator/Constraints/RangeValidator.php

Lines 36 to 43 in 3cfdc9e

    
           if (!is_numeric($value) && !$value instanceof \DateTimeInterface) { 
        
               $this->context->buildViolation($constraint->invalidMessage) 
        
                   ->setParameter('{{ value }}', $this->formatValue($value, self::PRETTY_DATE)) 
        
                   ->setCode(Range::INVALID_CHARACTERS_ERROR) 
        
                   ->addViolation(); 
        
               return; 
        
           }

and basically get rid of UnexpectedTypeException for this case.

stoccc · 2018-07-10T19:57:15Z

Imho a validator should not throw exceptions if you ask to validate unexpected data types, that could come from user or whatever untrusted, it should just add violations.

ogizanagi · 2018-07-11T06:26:36Z

I agree with @ro0NL , we should handle it per case in each validator. Relates to #26477 (comment) too where I also suggested this. Handling this properly in each validator would not interrupt the validation and keep adding other violations (and answer the AllValidator issue too).
Also we cannot just catch UnexpectedTypeException as this can also be logic exceptions due to a developer mistake that should be fixed (i.e the constraint class check).

ro0NL · 2018-07-11T07:06:19Z

Also i was wondering if we can somehow leverage the Type constraint/validator, in terms of forwarding this validation. To do all the work basically, more concise and to avoid a new error code/message for each constraint i guess.

Maybe with some helper, it could also ease the migration of custom constraint validators.

xabbuh · 2018-09-24T08:42:04Z

@ro0NL Your example in #27917 (comment) is IMO not good in terms of DX. The goal of this PR is precisely to lower the burden when writing constraint validators. But @ogizanagi has a valid point in the exception could as well have been thrown because of the wrong constraint being passed.

What do you think about a different approach like the one @webmozart suggested in #12312?

ro0NL · 2018-09-24T08:50:47Z

Oh wow :) @webmozart created all the tickets already :D

His suggestion indeed looks very good! Except im not sure about proposed strict/loose varying in Type.. we dont really need that IMHO (now we have normalizers as well).

We still agree a constraint violation should be favored over an exception right?

Your example in #27917 (comment) is IMO not good in terms of DX

Still.., we need to trigger type validation somewhere right?

xabbuh · 2018-09-24T10:18:16Z

@ro0NL I still think it's okay to throw an exception in the validator which will then be transformed into a proper constraint violation.

@ogizanagi made another good suggestion in #26477 (comment):

Or perhaps we should introduce a new UnexpectedValueTypeException extending UnexpectedTypeException that'll be caught and transformed into a violation by the component.
We should also inspect more thoroughly other validators.

ro0NL · 2018-09-24T10:25:30Z

👍 for UnexpectedValueTypeException

xabbuh · 2018-09-25T08:49:54Z

PR updated with a new UnexpectedValueException which will be caught by the validator and transformed into a constraint violation

ro0NL · 2018-09-25T09:10:14Z

src/Symfony/Component/Validator/Exception/UnexpectedValueException.php

+{
+    private $expectedType;
+
+    public function __construct($value, string $expectedType)


what about array $expectedTypes. Right now array or Traversable is not really a friendly translation parameter. We should leverage the new message formatter for this :)

That assumes it's all unions. It will prevent consumers to use more complicated rules in future, e.g. intersection types. Also, I'm interested how would you improve message array or Traversable

maybe

throw UnexpectedValueException::notUnionOf($value, $type, ...$type); throw UnexpectedValueException::notIntersectionOf($value, $type, ...$type);

ro0NL · 2018-10-04T09:12:12Z

From #28645 (comment) not sure the current approach is blocking for @nicolas-grekas

Alternatively, what about exposing the variables and pre-validate as such in i.e. abstract SimpleConstraintValidator:

getConstraintClasses(): array { return [Some::class]; }
getValidTypes(): array { return ['string']; }
allowsNull(): bool { return true; }

E.g. getConstraintClasses() could be guessed, similar like bundle extension class is guessed.

Also #27917 (comment) is still considerable IMHO, that solves translation messages, complex type validation and overall consistency.

Your example in #27917 (comment) is IMO not good in terms of DX. The goal of this PR is precisely to lower the burden when writing constraint validators

I think we can simplify it by adding some util to the base class, e.g. $this->validType().

xabbuh · 2018-10-04T09:37:02Z

Well, the main idea for this PR is not to centralise logic. I mean I would be fine with adding more code to our core constraint validators to achieve the same. The code added here is more important for individual constraint validators written for applications where users do not want to deal with more code.

ro0NL · 2018-10-04T09:46:43Z

Well, the main idea for this PR is not to centralise logic.

But it does exactly that, inferring the constraint violation thru exception in RecursiveContextualValidator. Meaning the constraint might behave differently between validator implementations? It feels a bit like a trick, compared to raising a pure violation from the constraint validator (one way or another).

nicolas-grekas · 2018-10-20T20:54:30Z

Do you think we can resolve this before the end of the month to have it in 4.2?

xabbuh · 2018-10-21T09:19:41Z

From my point of view the PR is finished. Do you think we should take another direction?

ro0NL · 2018-10-23T07:28:29Z

src/Symfony/Component/Validator/Constraints/CollectionValidator.php

@@ -34,7 +35,7 @@ public function validate($value, Constraint $constraint)
        }

        if (!\is_array($value) && !($value instanceof \Traversable && $value instanceof \ArrayAccess)) {
-            throw new UnexpectedTypeException($value, 'array or Traversable and ArrayAccess');
+            throw new UnexpectedValueException($value, 'array or Traversable and ArrayAccess');


i still think we need to tackle this being translator friendly, it'll only work for english

e.g. different messages like

This value should be of type {{ type }} (generic)

This value should be array accessible

This value should be iterable

This value should be a countable

what about using array|(Traversable&ArrayAccess)?

sounds like a plan yes :) the messages dont have to be pretty (tailored), but should be correct.

We don't translate exception messages

the issue happens here: https://github.com/symfony/symfony/pull/27917/files#diff-d46c902789b437519780ee8110ecb5e9R807 (in RecursiveContextualValidator)

@ostrolucky we do, see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Validator/Violation/ConstraintViolationBuilder.php#L149

ro0NL · 2018-10-23T08:36:54Z

src/Symfony/Component/Validator/Constraints/AllValidator.php

@@ -34,7 +35,7 @@ public function validate($value, Constraint $constraint)
        }

        if (!\is_array($value) && !$value instanceof \Traversable) {
-            throw new UnexpectedTypeException($value, 'array or Traversable');
+            throw new UnexpectedValueException($value, 'array or Traversable');


lets use iterable here

nicolas-grekas · 2018-10-24T07:54:19Z

Thank you @xabbuh.

…dation (xabbuh) This PR was merged into the 4.2-dev branch. Discussion ---------- [Validator] catch any UnexpectedValueException on validation | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #12312 | License | MIT | Doc PR | Commits ------- fa35860 catch any UnexpectedValueException on validation

This PR was merged into the 5.4 branch. Discussion ---------- [Validator] fix the exception being thrown | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | | License | MIT An `UnexpectedValueException` is caught and transformed into a violation (`UnexpectedTypeException` indicates a misconfiguration of a constraint and is not caught). see also #27917 Commits ------- 3a8f10b fix the exception being thrown

xabbuh added this to the next milestone Jul 10, 2018

carsonbot added Status: Needs Review Validator Feature labels Jul 10, 2018

xabbuh force-pushed the issue-14943 branch 2 times, most recently from 9d30a98 to fac281d Compare September 25, 2018 08:48

xabbuh changed the title ~~[Validator] catch any UnexpectedTypeException on validation~~ [Validator] catch any UnexpectedValueException on validation Sep 25, 2018

xabbuh force-pushed the issue-14943 branch from fac281d to c989d0a Compare September 25, 2018 08:51

xabbuh requested a review from ogizanagi September 25, 2018 08:52

ro0NL reviewed Sep 25, 2018

View reviewed changes

ogizanagi approved these changes Sep 25, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Sep 25, 2018

ro0NL mentioned this pull request Sep 30, 2018

[Validator] Standardize constraint validators #28645

Closed

ogizanagi mentioned this pull request Oct 2, 2018

[Validator][DoctrineBridge][FWBundle] Automatic data validation #27735

Merged

3 tasks

dunglas approved these changes Oct 2, 2018

View reviewed changes

nicolas-grekas removed this from the next milestone Oct 20, 2018

nicolas-grekas added this to the 4.2 milestone Oct 20, 2018

nicolas-grekas approved these changes Oct 23, 2018

View reviewed changes

ro0NL reviewed Oct 23, 2018

View reviewed changes

nicolas-grekas added Status: Needs Work and removed Status: Reviewed labels Oct 23, 2018

catch any UnexpectedValueException on validation

fa35860

xabbuh force-pushed the issue-14943 branch from c989d0a to fa35860 Compare October 24, 2018 07:52

nicolas-grekas added Status: Reviewed and removed Status: Needs Work labels Oct 24, 2018

nicolas-grekas merged commit fa35860 into symfony:master Oct 24, 2018

xabbuh deleted the issue-14943 branch October 24, 2018 07:55

ogizanagi mentioned this pull request Oct 24, 2018

AllValidator should not throw when not traversable is passed #26477

Closed

ro0NL mentioned this pull request Oct 24, 2018

[Validator] New UnexpectedValueException symfony/symfony-docs#10551

Closed

This was referenced Oct 25, 2018

[Validator] catch any UnexpectedValueException on validation symfony/symfony-docs#10563

Closed

[Validator] catch any UnexpectedValueException on validation symfony/symfony-docs#10611

Closed

This was referenced Nov 3, 2018

Release v4.2.0-BETA1 #29072

Closed

Release v4.2.0-BETA1 #29073

Merged

xabbuh mentioned this pull request Jan 2, 2024

[Validator] fix the exception being thrown #53350

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Validator] catch any UnexpectedValueException on validation #27917

[Validator] catch any UnexpectedValueException on validation #27917

xabbuh commented Jul 10, 2018 •

edited

Loading

xabbuh commented Jul 10, 2018

ro0NL commented Jul 10, 2018

stoccc commented Jul 10, 2018

ogizanagi commented Jul 11, 2018

ro0NL commented Jul 11, 2018 •

edited

Loading

xabbuh commented Sep 24, 2018

ro0NL commented Sep 24, 2018

xabbuh commented Sep 24, 2018

ro0NL commented Sep 24, 2018

xabbuh commented Sep 25, 2018

ro0NL Sep 25, 2018 •

edited

Loading

ostrolucky Oct 3, 2018

ro0NL Oct 4, 2018

ro0NL commented Oct 4, 2018 •

edited

Loading

xabbuh commented Oct 4, 2018

ro0NL commented Oct 4, 2018

nicolas-grekas commented Oct 20, 2018

xabbuh commented Oct 21, 2018 •

edited

Loading

ro0NL Oct 23, 2018

ro0NL Oct 23, 2018

nicolas-grekas Oct 23, 2018 •

edited

Loading

ro0NL Oct 23, 2018

ostrolucky Oct 23, 2018

ro0NL Oct 23, 2018 •

edited

Loading

nicolas-grekas Oct 23, 2018

ro0NL Oct 23, 2018

nicolas-grekas commented Oct 24, 2018

[Validator] catch any UnexpectedValueException on validation #27917

[Validator] catch any UnexpectedValueException on validation #27917

Conversation

xabbuh commented Jul 10, 2018 • edited Loading

xabbuh commented Jul 10, 2018

ro0NL commented Jul 10, 2018

stoccc commented Jul 10, 2018

ogizanagi commented Jul 11, 2018

ro0NL commented Jul 11, 2018 • edited Loading

xabbuh commented Sep 24, 2018

ro0NL commented Sep 24, 2018

xabbuh commented Sep 24, 2018

ro0NL commented Sep 24, 2018

xabbuh commented Sep 25, 2018

ro0NL Sep 25, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ro0NL commented Oct 4, 2018 • edited Loading

xabbuh commented Oct 4, 2018

ro0NL commented Oct 4, 2018

nicolas-grekas commented Oct 20, 2018

xabbuh commented Oct 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas Oct 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ro0NL Oct 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas commented Oct 24, 2018

xabbuh commented Jul 10, 2018 •

edited

Loading

ro0NL commented Jul 11, 2018 •

edited

Loading

ro0NL Sep 25, 2018 •

edited

Loading

ro0NL commented Oct 4, 2018 •

edited

Loading

xabbuh commented Oct 21, 2018 •

edited

Loading

nicolas-grekas Oct 23, 2018 •

edited

Loading

ro0NL Oct 23, 2018 •

edited

Loading