Skip to content

[HttpKernel] Fix static code analysis warning #19960

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

[HttpKernel] Fix static code analysis warning #19960

wants to merge 3 commits into from

Conversation

ro0NL
Copy link
Contributor

@ro0NL ro0NL commented Sep 18, 2016

Q A
Branch? 2.7
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #19867
License MIT
Doc PR reference to the documentation PR, if any

Before:

[Symfony\Component\Debug\Exception\ContextErrorException]                                                                                                                                                                                                                                                                                                
  Catchable Fatal Error: Argument 1 passed to Symfony\Component\DependencyInjection\Loader\FileLoader::__construct() must be an instance of Symfony\Component\DependencyInjection\ContainerBuilder, instance of Symfony\Component\DependencyInjection\Container given

After

[InvalidArgumentException]                                                                                                                      
  The container must be an instance of Symfony\Component\DependencyInjection\ContainerBuilder, got Symfony\Component\DependencyInjection\Container.

Cosmetic only (better error though), but fixes static code analysis warnings.

Ideally in 4.0 the signature is updated...

@ro0NL ro0NL changed the title test container type [HttpKernel] Fix static code analysis warning Sep 18, 2016
* @return DelegatingLoader The loader
*/
protected function getContainerLoader(ContainerInterface $container)
{
if (!$container instanceof ContainerBuilder) {
throw new \DomainException(sprintf('Container must be an instance of Symfony\Component\DependencyInjection\ContainerBuilder, got %s', get_class($container)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just my opinion but I would prefer see The first argument of ...\Kernel::getContainerLoader() must be an instance of... for faster understanding

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure.. i tend to not couple context and domain. The message is about the container state, not whether it's the first, second or 10th argument.

It can be a DX improvement.. but to be honest i think when calling getContainerLoader($myContainerVariableName) and it throws Container must be ... is pretty straightforward ;-)

Copy link
Member

@chalasr chalasr Sep 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got your point, both are arguable I think.
Edit: Got it if your message was $container must be :) (It's how Guard does it for instance)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im lost on symfony and exceptions. Based on this ref i think we should do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree the current message is clear enough. The stacktrace is here in case we need more clues.

* @return DelegatingLoader The loader
*/
protected function getContainerLoader(ContainerInterface $container)
{
if (!$container instanceof ContainerBuilder) {
throw new \InvalidArgumentException(sprintf('The container must be an instance of Symfony\Component\DependencyInjection\ContainerBuilder, got %s.', get_class($container)));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- throw new \InvalidArgumentException(sprintf('The container must be an instance of Symfony\Component\DependencyInjection\ContainerBuilder, got %s.', get_class($container)));
+ throw new \InvalidArgumentException(sprintf('The container must be an instance of %s, got %s.', ContainerBuilder::class, get_class($container)));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Targets 2.7 / PHP 5.3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Sorry. I saw the target branch after my comment but lose my connection, so was unable to remove my comment :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only option would be to change the type hint of the method, but given that this is a protected method, this is not possible and very unlikely to happen, so it looks like a won't fix to me.

Copy link
Contributor Author

@ro0NL ro0NL Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh.. i'd say this change + 4.0 changelog about changing signature. Otherwise this change only (ie. not sure why this would be "wont fix").

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be "won't" fix even in 4.0 because we have a policy of:

  1. issuing a deprecation notice in the current version
  2. allow people to fix their in the same version where the notice appeared
  3. then make the change. If the notice can't

Since 2. is not possible here, neither is 3. This ensures a continuous upgrade path.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure i follow.. this is only cosmetic. It crashed before as well... what should we deprecate?

Copy link
Member

@nicolas-grekas nicolas-grekas Oct 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about changing the method signature to ContainerBuilder instead of ContainerInterface, which is not possible, because there is no continuous upgrade path (except creating a new method or deprecate extending this one, but is it worth it?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also about performance and not checking types ourselves. It crashed before, it will throw an exception, and anyway, use cases where you really pass a non-ContainerBuilder are pretty small. So, I really think this is not worth it. At the minimum, why not just change the phpdoc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, i tend to look at it more abstract. Ie. the current design is semi-flawed, and could be fixed imo. I dont like to depend on PHP what will happen..

why not just change the phpdoc

Not sure.. imo. it's more confusing.

Lets keep it as is then 😕

@@ -672,10 +672,16 @@ protected function dumpContainer(ConfigCache $cache, ContainerBuilder $container
*
* @param ContainerInterface $container The service container
*
* @throws \InvalidArgumentException When the container is not an instance of ContainerBuilder
Copy link
Member

@chalasr chalasr Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @throws annotation should go after the @return one (ref #18975)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants