I'm hitting this issue as well but from another angle with upgrading an old Symfony 3.4 to 4.3. There is a deprecation notice regarding @ParamConverter which suggests this:

@Route(methods={"GET", "POST"}, path="/create", name="_create")
@Route(methods={"GET", "POST"}, path="/update/{activity}", name="_update", requirements={"activity": "\d+"})
@ParamConverter("activity", class="App\Entity\Activity", options={"repository_method": "findActivityWithJoins"})

should be converted into this:

@Route(methods={"GET", "POST"}, path="/create", name="_create")
@Route(methods={"GET", "POST"}, path="/update/{activity}", name="_update", requirements={"activity": "\d+"})
@Entity("activity", class="App\Entity\Activity", expr="repository.findActivityWithJoins(activity)")

However this won't work, because the activity variable is not available when you enter the controller method from the _create route. I can't use expr="activity ? repository.findActivity(activity)" and it's also not possible to use expr="_route_params in ['activity'] ? repository.findActivityWithJoins(activity)") so there is no workaround so far that I've found to work.

Is there any progress on this issue or maybe a workaround that I am missing somehow?

//cc @nicolas-grekas

@steve-todorov Coincidentally - I've just encountered this same problem whilst trying to resolve deprecations. I think I might have figured a workaround tho' :)

Old:

     * @Route("/add")
     * @Route("/edit/{id}")
     * @ParamConverter("client", options={"repository_method"="findApproved"})

New:

     * @Route("/add", defaults={"id"=null})
     * @Route("/edit/{id}")
     * @Entity("client", expr="repository.findApproved(id)")

The defaults option means that there is an "id" declared even on the /add route, avoiding the explosion.

This does mean that the repository method is getting passed a null, and needs to be able to handle that, but it seemed to already handle that in my case.

Ha! I haven't thought of that! Thanks for sharing this workaround - works just fine! :)

We encountered the same issue when trying to use ExpressionLanguage in our project.

I would just like to point out few things/ideas

• parser should only parse exprerssion (as it name is suggesting) and not checkng for it's existance/value
• when encountering the non existing value, it should evaluate to null (as in Javas's EL/JUEL which has much in common with Symfony's EL)
• it would be the best to have optional parameter in ExpressionLanguage (e.g. strictMode=true) to preserve backcompatibility

In Contao CMS Version 4.10 ExpressionLanguage is now used also for evaluating some input fields. Here one will have the same issue as described by tolecar:

We encountered the same issue when trying to use ExpressionLanguage in our project.

I would just like to point out few things/ideas

• parser should only parse exprerssion (as it name is suggesting) and not checkng for it's existance/value
• when encountering the non existing value, it should evaluate to null (as in Javas's EL/JUEL which has much in common with Symfony's EL)
• it would be the best to have optional parameter in ExpressionLanguage (e.g. strictMode=true) to preserve backcompatibility

I thus support the opinion that a non existing value should evaluate to null instead of throwing an exception.

We solved the issue by extending ExpressionLanguage class and a few more. It is not a beauty, but the classes are written in such a way that we didn't have much options.

Few days ago I published it on the github & packagist as separate library so you can try to use it.
So far seems that we haven't lost any of original Symfony EL features.

You can check it up on https://github.com/zef-dev/zef-expression-language and https://packagist.org/packages/zef-dev/zef-expression-language

it's also not possible to use expr="_route_params in ['activity'] ? repository.findActivityWithJoins(activity)") so there is no workaround so far that I've found to work.

what you want is actually checking that 'activity' is in the route params keys, not that the array of route params is the string activity.

what you could do is add a default of null for activity in the first route.

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

It's definitely not resolved, I just stumbled on it too while using the Expression Language in a custom project.

Yes, our workaround has been to completely side step use of Expression Language if/when a given key in the expression isn't "guaranteed" in the data available/provided for evaluation. From the consumer-side of this package, I do think evaluating non-existent identifiers to NULL might be a better design choice than throwing an exception or, at least, better as EL behavior controlled through a configurable option.

My only workaround to this issue is to specifically catch the exception message and try again, which is really dirty code but at least allows you to use the expression language on arrays that may have missing keys. I hope this helps someone:

tryagain:

try {

    if ($expressionLanguage->evaluate($expression, $data)) {
        // Success
    }

}

catch (\Symfony\Component\ExpressionLanguage\SyntaxError $e) {

    // Match the error message and variable name
    if (preg_match('/^Variable "(?<var>[^"]+)" is not valid around position [0-9]+ for expression/', $e->getMessage(), $matched)) {

        // Check that it is not in the data array (likely the cause)
        if (!array_key_exists($matched['var'], $data)) {
            $data[$matched['var']] = null;
            goto tryagain;
        } else {
            throw $e;
        }
    } else {
        throw $e;
    }

}

@prof83 That your workaround is coded using GOTO (lots of passion around this one on both sides) and regular expression pattern matching on the exception message itself just makes this all the more interesting, I think. It could probably be refactored as a DO-WHILE as a peace offering.

I think this Symfony Expression Language behavior is the subject other other issues that have been opened (e.g. #41306), although referencing different Symfony versions (2.8 versus 5.2.7).

I think we should keep the generated code as simple as possible. Thus not do anything to prevent the notice in the generated code.

BUT I would suggest adding support for the nullsafe operator and the null coalescing!

Anyone up for giving it a try?