-
Notifications
You must be signed in to change notification settings - Fork 28
Better exception messages for the Service Container. #1922
Comments
Could you post a link to where the exception is thrown? |
@tillkruss I don't know what you mean. |
@frankdejonge: I mean what's the exception that's thrown if a dependency can't be resolved. I wanted to check it out how easy it is to fix this. |
Actually, this should be shown in the exception message. The container keeps a build stack and adds the previous resolved classes from the chain to the exception message as you can see here: Is this not working for you? Can you provide some code in order to let us recreate it? |
@driesvints if I remember correctly it's when dependency is resolved that depends on something that's not instantiable. The error message could be try/catch'ed around the call that resolved the dependencies and retrown with the service identifier (or classname) that was the root of the dependency tree. |
Transferred this issue to the ideas repository instead. |
The issue
When the container is not able to construct one of its dependencies you don't know which class it was trying to resolve initially. This makes it very hard figure out which dependency was being resolved in the first place.
Possible solution
If exceptions are caught and re-thrown when a dependency is resolved a dependency chain could be built up. This would be used in the final message to give a better hint why a dependency cannot be resolved.
The text was updated successfully, but these errors were encountered: