NOT ENUM can unexpectedly fail when "CHECK_MODE_EXCEPTIONS" is set

[asaliev]

Version: 5.2.7

What happened
Unexpected behavior when using the CHECK_MODE_EXCEPTIONS mode combined with a "not": { "enum": ["bar"] } schema, will result in a thrown exception

Consider the following example:

<?php

require_once 'vendor/autoload.php';

$schema = [
    '$schema' => "http://json-schema.org/draft-04/schema#",
    "type" => "object",
    "properties" => [
        "foo" => [
            "type" => "string",
            "not" => [
                "enum" => ["bar"]
            ]
        ]
    ]
];

$data = (object)[
    "foo" => "baz"
];

$validator = new JsonSchema\Validator;
$result = $validator->validate($data, $schema, JsonSchema\Constraints\Constraint::CHECK_MODE_EXCEPTIONS);

This will fail unexpectedly with the error message PHP Fatal error: Uncaught JsonSchema\Exception\ValidationException: Error validating /foo/foo: Does not have a value in the enumeration ["bar"] in /path/to/json-schema/src/JsonSchema/Constraints/BaseConstraint.php:57 which is not the expected behavior, since if you run the validator without the CHECK_MODE_EXCEPTIONS constraint, there will be no error.

What I expected to happen
I think the expected behavior should be when using CHECK_MODE_EXCEPTIONS mode, the not constraint should not fail instantly if the child constraint failed, since not has to negate the results first.

Possible solution
Looks like it's because of UndefinedConstraint is not aware of the CHECK_MODE_EXCEPTIONS during checking the not construct and when it attempts to match bar vs an enum of [baz] further down the chain it fails with an exception which propagates all the way out of the validator.

[DannyvdSluijs]

@asaliev in an attempt to cleanup this repo we are trying to filter the issues and see which ones might be closed. Is it safe to assume this is a rather old issue, which sadly was left unanswered?
You reported the issue to be in version 5.2.7, currently we are working on getting the v6.0.0 version out. Did you try this on the current master branch if it is still reproducible?

I also noticed #553 is open for fixing this and targeting the v5.x.x branch. Due to time being an issue we are currently not planning any porting of fixes to v5.

[asaliev]

@DannyvdSluijs I'm no longer involved in the project that used this library.

I believe you can close this issue.

There is a unit test with a fixture in #553 that will fail if the issue still exists on v6, in case someone wants to take a look at it in the future.