-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
DX: better error message if factory class is empty #18547
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
Conversation
@iltar (and @symfony/deciders ) would be better to vote using real comments IMHO, so the other deciders can get a notification about it, WDYT? |
@nicolas-grekas agreed about deciders (otherwise GH won't take votes into account either btw). This is even required for veto votes btw, as we must explain them (and we cannot with reactions), and it also allows to see the history of votes of the core team (for vote changes for instance). However, @iltar is not a decider, so it is fine to show support through reactions IMO (avoids spamming the discussion and shows a total of votes) 👍 for this |
Oups, I thought @iltar you were a decider sorry :) |
@stof explains pretty much why I use that button instead ^.^ I was a bit in a hurry to write a proper reply. I think the sentence is a bit hard to read, what about something like:
|
@nicolas-grekas I think we should even validate this earlier, in the XML and Yaml loader, as they can give more detailed feedback. What do you think about that ? |
Actually, I was wondering why the example XML did pass the XSD check at all. Turns out the |
Actually, I was wondering why the example XML did pass the XSD check at
all. Turns out the |callable| type allows to define an |id| attribute.
Does anyone know why this was added initially?
i was surprised by that as well but am not deep enough into the code to
know where to look for that or what to do. i guess removing it could
annoy people that have a meaningless id lying around, maybe just
deprecate and remove it in symfony 4 only.
also surprised that it looks like "something" comes up with an empty
string for class instead of noticing that its neither specified
explicitly nor can be pulled from a service reference. if you find a
place to discover the incomplete specification, all the better (though
it might be possible for a compiler pass to fill in missing things, so
not allowing a factory with neither class nor service in xml / yml could
break things)
i am happy to improve the message if you agree iltar's proposal is the
way we should formulate it. should i do that or does somebody want to
dig deeper into the code?
|
I agree this comes late in the process. Until someone fixes that, let's enhance the message here, I like @iltar suggestion. |
@@ -692,7 +692,7 @@ private function addServices() | |||
return $publicServices.$privateServices; | |||
} | |||
|
|||
private function addNewInstance(Definition $definition, $return, $instantiation) | |||
private function addNewInstance(Definition $definition, $return, $instantiation, $id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i realized that the id parameter was removed since symfony 2 (i tested this in my project with symfony 2...)
not sure if its ok to pass the id around just for the purpose of the error message, but without the id the message becomes a lot less useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a private method so I don't think it really matters that much. For the sake of DX, I'd say it's a good case to pass it along because it's required to build the error message.
@dbu tests need some love :) |
@nicolas-grekas fixed travis-ci. now only appveyor has a complaint left. can you help me here? it feels like this is not related to my change, right? |
right! |
@nicolas-grekas that error pops up more often; https://ci.appveyor.com/project/fabpot/symfony/build/1.0.8342#L1331 |
See #18576 |
anything left to do in this PR? or do i wait for #18576 to be merged and
then rebase?
|
Thank you @dbu. |
This PR was merged into the 3.1-dev branch. Discussion ---------- DX: better error message if factory class is empty | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | ? | Fixed tickets | - | License | MIT | Doc PR | - i was trying to debug this service configuration: ```xml <service id="repository.user" class="Doctrine\ORM\EntityRepository"> <argument>%user_entity_class%</argument> <factory id="doctrine.orm.default_entity_manager" method="getRepository"/> </service> ``` Turns out i should have used `<factory service=...` instead of `<factory id=...` but the error message does not even tell which service is wrong. The same happens when only specifying the `method=` attribute. The current exception message tells: Cannot dump definition because of invalid class name ('') With this change, the message at least tells the context, hopefully helping the developer debug the issue: Empty class for factory of service repository.user and no factory service specified Commits ------- 0999326 better error message if factory class is empty
@nicolas-grekas Should we really treat this as a new feature instead of backporting this to older versions too? Imo this classifies as a kind of bugfix. |
@xabbuh That's one of the points I wanted to clarify in my doc PR about where to merge such changes. In the past, we had 2 strategies about exception messages changes: merge them as bug fix or as new features. People could rely on the error message in their code (even if this is clearly a bad practice), so changing the text in a patch release seems like a bad idea. Also, it does not fix any bug per se. That being said, in this specific case, as the exception is during the container dump, I tend to agree with @xabbuh that it could have been merged as a bug fix. Conclusion: Qualifying a code change as a bug fix or a new feature is really really hard :) |
i was trying to debug this service configuration:
Turns out i should have used
<factory service=...
instead of<factory id=...
but the error message does not even tell which service is wrong. The same happens when only specifying themethod=
attribute. The current exception message tells:With this change, the message at least tells the context, hopefully helping the developer debug the issue: