Repository navigation
Add ContainerException::getContainer() #17
Description
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.
Reacted by Miguel Muscat
Activity
mnapoli commentedon 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 commentedon Jun 29, 2017
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 commentedon Jul 14, 2023
2.x is out. Gentle reminder.