Open XedinUnknown opened 7 years ago
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).
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.
2.x is out. Gentle reminder.
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()
toContainerExceptionInterface
, which would returnContainerInterface|null
, just in case there really somehow isn't a container associated with it for some reason.