container icon indicating copy to clipboard operation
container copied to clipboard

Add `ContainerException::getContainer()`

Open XedinUnknown opened this issue 8 years ago • 3 comments

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.

XedinUnknown avatar Jun 29 '17 09:06 XedinUnknown

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).

mnapoli avatar Jun 29 '17 09:06 mnapoli

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 avatar Jun 29 '17 09:06 XedinUnknown

2.x is out. Gentle reminder.

XedinUnknown avatar Jul 14 '23 16:07 XedinUnknown