- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 335
Open
Labels
Description
For example, developer make typo in Provide[...]
:
container.py
class ApplicationContainer(containers.DeclarativeContainer):
some_service = providers.Singleton(object)
app.py
# FastAPI
@app.get("/")
@inject
async def some_handler(service = Depends(Provide["sOme_service"])): # suppose there is a typo in the name of the container attribute
# `service` will be <dependency_injector.wiring.Provide object at 0x7f59daf8c580>
pass
I've tried this approach, but it doesn't work for the Singleton:
Provide["some_service", required()] # AttributeError: 'dependency_injector.providers.Singleton' object has no attribute 'required'
So, how to crash app in case if dependency cannot be resolved?
JanPalasek, rmk135 and chschroeder
Activity
gtors commentedon Dec 14, 2021
Why not raise an exception here?
python-dependency-injector/src/dependency_injector/wiring.py
Lines 546 to 547 in 541131e
tarohi24 commentedon Dec 31, 2021
+1 It would be great to have an option to raise an exception when failing to resolve a dependency.
JanPalasek commentedon Jan 30, 2022
Does this work for modules not mentioned in wire function? Mb implement into inject decorator?
jeffmace commentedon Sep 2, 2022
I'm getting started with python-dependency-injector and have been tripped up by some self-imposed wiring errors. The end result is that my methods get called with
Provide
object when I would prefer anException
explaining the issue.My issues have fallen into two buckets:
Provide
. I have a fix for this which replacespython-dependency-injector/src/dependency_injector/wiring.py
Line 235 in 3858cef
Container
has not been wired for theProvider
. This could be that no containers have been wired or that the wrong type has been wired. I believe the solution is to update_get_sync_patched
so it comparespatched.reference_[injections|closing]
withpatched.[injections|closing]
to detect missing values. TheModifier
could be overloaded to handle these cases so the functionality is opt-in and doesn't change the interface. If that is not desired, another parameter could be added to_Marker
which indicates the desired behavior.I can submit a PR for the first case, and take a look at implementing the second. But I wanted to get some input on the approach before beginning. I realize these issues are bugs in my application and not the library, but these changes would make debugging the issues easier.