How to handle invalid ids passed to has() and get()
shochdoerfer opened this issue · comments
Not sure if this is a problem we need to tackle or not but I thought it might be useful to bring it to the table ;) In bitexpert/disco the ids passed to has() and get() map to class methods which means we are limited to the characters allowed in method names (e.g. no dots allowed). Currently neither has() nor get() define that it is possible to throw an InvalidArgumentException (at least not according to the docblock documentation :P). For get() I could throw an ContainerException but that seems to be too generic for my use case. Any thoughts?
TBH I throw a InvalidArgumentException in PHP-DI: https://github.com/PHP-DI/PHP-DI/blob/master/src/DI/Container.php#L105 Never had any issues, I would change it if I find one. But looking back on it I doubt the usefulness of the base ContainerException. If one wants to catch all exceptions thrown by the container, it can catch Exception and that would do the job. Anyway that's not really the point :) (and I'm just speaking in my name of course, maybe others will disagree)
Hey Stephan,
Your Disco container might be included in a composite container, along other containers.
If it is not valid for you to have dots in a name, it might still be possible for other containers in the list.
If your container throws a ContainerException or an InvalidArgumentException, it will break the composite container behaviour.
My take on this would be:
- return false on
has - throw
NotFoundExceptiononget
because this is really what happens: Disco cannot contain an identifier with ".", therefore it does not have it and should treat this case as a "entry not found".
@mnapoli I would not want to throw an exception that is not explictly stated in the docblock comment. Because in that case the caller always needs to catch \Exception which is a major pain point for when using most libs.
@moufmouf I would assume that throwing a ContainerException would not break the composite container behaviour. For any other exception yes, that may be the case. That was the main reason why I am asking.
Your "solution" is exactly what I had in mind and I might head into that direction. I was just wondering if it would make any sense to be able to check the input parameter of both methods to be able to react in a different way.
Because in that case the caller always needs to catch \Exception which is a major pain point for when using most libs.
Yep but my point about ContainerException was exactly that: what's the difference between catching ContainerException or \Exception? How is it a major pain point? The container catches exceptions thrown while constructing objects anyway.
Btw if NotFoundException is an option for you then I agree it's the best solution. I initially thought you didn't want to go that way for some reason.
hello, I agree with @moufmouf suggested behavior on this one.
return false on has
throw NotFoundException on getbecause this is really what happens: Disco cannot contain an identifier with ".", therefore it does not have it and should treat this case as a "entry not found".
@mnapoli you got me wrong (I think). The major pain point is that one does not know which exception to catch. The documentations says exception X is thrown but also Y comes through.
As for the rest of the discussion that`s for the feedback, will do it as described.