Skip to content
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

Add ContainerException::getContainer() #17

Open
XedinUnknown opened this issue Jun 29, 2017 · 3 comments
Open

Add ContainerException::getContainer() #17

XedinUnknown opened this issue Jun 29, 2017 · 3 comments

Comments

@XedinUnknown
Copy link

It's seems rather weird that an exception which relates to a container has no means of retrieving the container instance. I suggest adding getContainer() to ContainerExceptionInterface, which would return ContainerInterface|null, just in case there really somehow isn't a container associated with it for some reason.

@mnapoli
Copy link
Member

mnapoli commented Jun 29, 2017

That would be a huge bc break though. And in which scenario would that be useful? I've never seen such a need (but that's just my own experience).

@XedinUnknown
Copy link
Author

Hi! Yes, this is totally for v2.0, due to the BC break. Not sure how I hadn't noticed it earlier in container-interop. If added, it would break implementations, though; the consumers would not have to be changed.

This could be useful in any scenario where you would need to know which container caused an error. As such, if you have generic code that retrieves services and does something with them, and you have some generic exception handling in high-level app code. then it could be extremely useful to be able to tell which container caused the problem. The container can then be used to display a more helpful message, or for debugging purposes.
A particularly important scenario is where you are dealing with a composite container, such as my implementation. Composite containers are very useful in a truly modular system, and I imagine that I am not alone in this use case.

In any case, IMHO conceptually you should be able to understand which container caused the error from the exception alone, without having prior reference to the container, or knowledge of the implementation or hierarchy of the container.

@XedinUnknown
Copy link
Author

2.x is out. Gentle reminder.

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

No branches or pull requests

2 participants