What way to determinate what concrete constraint failed? foreach + instanceof?

Maybe can we use reflection for generation error names from constants name by they values?

@Koc Just check $violation->getConstraint().

Reflection is slow. We won't change the error codes very often, so an explicit mapping should be fine.

@fabpot can you merge older branches into master so that this PR can be rebased ? It will be easier to review it when the diff does not include the changes of previous PRs

@stof As soon as I have a go on #12016, I'll merge everything and rebase this PR.

I think you used the wrong issue number in your comment

@stof No I haven't... ;)

you cheated 😄

This is rebased now. I also improved the UUID validator to give more helpful error codes.

Ready for review+merge.

ping @symfony/deciders

@weaverryan Could you check the names of the error constants for linguistic mistakes?

👍

I changed all constant names as suggested. @weaverryan I'd still like to have a check from a native speaker, if possible.

@Tobion I removed the internal flag and changed the type hint to "int" for setCode(). One should always use integers as error codes, even though this is not technically enforced at the moment for BC reasons.

there are still some mixed code references like https://github.com/webmozart/symfony/blob/issue7276-2/src/Symfony/Component/Validator/ConstraintViolationInterface.php#L133 (should probably be int|null) and https://github.com/webmozart/symfony/blob/issue7276-2/src/Symfony/Component/Validator/ConstraintViolation.php#L81 and some @var mixed code properties. But as the code can also be null, getErrorName does not work with this. So your snippet var_dump($violation->getConstraint()->getErrorName($violation->getCode())); is not safe to call.

@Tobion We can't change those. Since the old addViolation() is tagged as API and has the "mixed" type, that must be the same for the ConstraintViolation constructor and the getCode().

$violation->getConstraint()->getErrorName($violation->getCode()) is safe to call as long as the constraint is a core constraint (and as long as $violation->getCode() is not null). The code is guaranteed to be set by $violation->getConstraint(), so it also must be known to its getErrorName().

For generic code that must work with userland constraints also, you should wrap the call to getErrorName()within a try-catch statement. If no name can be found for a code, an exception will be thrown.

ping @symfony/deciders

I'd like to merge this today.

@webmozart I still don't see your argument that the error code can be used in a REST API. The error code is not unique, so if a users reports he received error_code: 1 it basically doesn't say anything to you.

@Tobion Of course you have to provide the name of the failing constraint as well, otherwise the code is useless.

We could make sure that the errors are unique by collecting them in a single class instead of within the individual constraints. Do you think that is a better solution?

Sketch:

namespace Symfony\Component\Validator;

final class Error
{
    const FILE_NOT_FOUND = 100;
    const FILE_EMPTY = 101;
    const IBAN_TOO_SHORT = 200;

    private function __construct() { ... }
}

$context->buildViolation('Error!')
    ->setCode(Error::FILE_NOT_FOUND)
    ->addViolation();

if (Error::FILE_NOT_FOUND === $violation->getCode()) {
    // ...
}

Well, the name must not really be unique as well. For example there are some as generic as INVALID_CHARACTERS which would fit to almost all violations.

Collecting errors in one place is worse IMO and also would not work with custom constraints anyway.
Maybe the error name must automatically append the constraint class or something like that to be able to really identify the source problem. On the other hand the class name + namespace is maybe not what people want to expose.

I dont see an issue with providing the constraint name along with the error code? It seems much more flexible than collecting the error codes into a single class or trying to ensure they're unique.

@webmozart thanks for your work on that.

Just my two cents: I still sort of prefer something unique-ish like an UUID, but I guess the constraint name + code is enough for me. I don't see the need of dealing with two keys (constraint, code) when the API consumers -which would be my main use case for this feature- can do fine with just a single one (code/uuid).

@Tobion I understand from your reply that you're not happy with the current solution, but what do you suggest to improve it?

IMO, the solution depends on the use case. For many cases, the error name is probably a better fit for the REST API than the numeric code. It will also make it easier to understand for people debugging their usage (as the error name can be understood). To make it useful, we just need to make sure that we don't use the same name for things which have actually different meaning (but this is not likely for names). But we don't need to ensure uniqueness. TOO_SHORT_ERROR is understandable and usable even when several constraints can complain about the value being too short.

👍

This reminds me of an issue I opened on the FosRestBundle repo few weeks ago FriendsOfSymfony/FOSRestBundle#842.

I needed an error code (error constant name or error numeric code) for my REST API as I wanted to obtain something like this http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#errors

By the way, have you seen this bundle which helps handling errors in REST APIs? https://github.com/TheBigBrainsCompany/TbbcRestUtilBundle/blob/master/README.md

This would be awesome to have! 👍

@lucascourot there are quite a few form related tickets open on the FOSRestBundle that need attention. Since I am personally not using the form component with FOSRestBundle (mostly because a large chunk of the REST related stuff I do is read only APIs) I need helping hands.

@lsmith77 I think my issue was mainly related to the fact that it wasn't possible to associate an error code to a validation constraint. Unless you extended each constraint class and added an error code attribute.
This PR fixes the problem.

@stanlemon This is merged already. The question is:

Right now, only those constraints which have multiple error causes have error codes. For example:

// caused by NotNull
$violation->getCode();
// => null

// caused by Length
$violation->getCode()
// => 1

Length::getErrorName($violation->getCode());
$violation->getConstraint()->getErrorName($violation->getCode());
// => "TOO_SHORT_ERROR"

Also, neither the numeric codes nor the error names are globally unique. So there are many constraints with the error code 1, there are also many constraints with a TOO_SHORT_ERROR. Hence the API output is only useful if you indicate the code/error name together with the name of the constraint causing that error.

Now my question: Is this a problem? Or do you prefer globally unique codes so that you know from the code exactly which constraint caused the error and what error it is? We could achieve this by replacing integers by UUIDs.

@webmozart but TOO_SHORT_ERROR is clear in all cases even if it is used in several places, because it has the same meaing in all cases: the value is too short

@stof I think you missed to point of the codes. That the value is too short is already clear from the message. The code is there so that devs can debug where (Length Constraint) and for what reason inside the constraint the validation failed.

@Tobion but for Rest API, most of the time, this code will be enough (while relying on the message itself to identify it is too short is not, given that the message can be updated to fix a typo in the wording for instance)

Yes "most of the time". But I prefer a system that covers it's intended functionality all the time.

For reference the follow up change: #15154