Source code for diwire.exceptions
[docs]
class DIWireError(Exception):
"""Represent a base class for all DIWire-specific failures.
Catch this type when you want to handle any DIWire error path without
matching each concrete exception class individually.
"""
[docs]
class DIWireInvalidRegistrationError(DIWireError):
"""Signal invalid registration or injection configuration.
Raised by registration APIs such as ``Container.add``,
``Container.add_factory``, ``Container.add_generator``,
``Container.add_context_manager``, and by ``ResolverContext.inject`` when
arguments are invalid.
Typical fixes include providing valid ``provides``/``scope``/``lifetime``
values, ensuring providers are callable with valid type annotations, and
avoiding reserved injection parameter names.
"""
[docs]
class DIWireInvalidProviderSpecError(DIWireError):
"""Signal an invalid provider specification payload.
This error is raised while validating provider metadata before resolver
generation, for example when explicit dependencies do not match the
provider signature.
"""
[docs]
class DIWireProviderDependencyInferenceError(DIWireInvalidProviderSpecError):
"""Signal that required provider dependencies cannot be inferred.
Common triggers are missing or unresolvable type annotations on required
provider parameters.
Typical fixes include adding concrete parameter annotations or passing
explicit ``dependencies=...`` during registration.
"""
[docs]
class DIWireDependencyNotRegisteredError(DIWireError):
"""Signal that a dependency key has no provider.
Raised by ``resolve``/``aresolve`` when strict mode is explicitly configured
(``missing_policy=MissingPolicy.ERROR`` with
``dependency_registration_policy=DependencyRegistrationPolicy.IGNORE``), when
a dependency cannot be auto-registered, or when no matching open-generic
registration exists.
Typical fixes include registering the dependency explicitly, enabling
autoregistration for eligible concrete types, or registering an open-generic
provider for the requested closed generic key.
"""
[docs]
class DIWireResolverNotSetError(DIWireError):
"""Signal use of ``resolver_context`` with no resolver source available.
Raised by ``ResolverContext.resolve``, ``ResolverContext.aresolve``,
``ResolverContext.enter_scope``, and ``ResolverContext.inject`` call paths
when neither an active resolver context nor a fallback container can serve
the call. For ``ResolverContext.inject``, fallback injection is disabled
when the fallback container uses ``use_resolver_context=False``, so calls
must pass ``diwire_resolver=...`` explicitly (or run under a bound resolver
context).
Typical fixes are entering a resolver context (``with container.compile():``)
or passing an explicit resolver via ``diwire_resolver=...``.
"""
[docs]
class DIWireScopeMismatchError(DIWireError):
"""Signal scope transition or resolution at an invalid scope depth.
Raised by ``enter_scope`` for invalid transitions and by ``resolve``/``aresolve``
when a dependency requires a deeper scope than the current resolver.
Typical fixes include entering the required scope (for example
``with container.enter_scope(Scope.REQUEST): ...``) or adjusting provider
scopes/lifetimes.
"""
[docs]
class DIWireAsyncDependencyInSyncContextError(DIWireError):
"""Signal sync resolution of an async dependency chain.
Raised by ``Container.resolve`` or sync cleanup paths when the selected
provider graph requires asynchronous resolution/cleanup.
Typical fix is switching to ``await container.aresolve(...)`` or using
``async with`` for scoped cleanup.
"""
[docs]
class DIWireInvalidGenericTypeArgumentError(DIWireError):
"""Signal invalid closed-generic arguments for an open registration.
Raised while matching open-generic registrations when a closed key violates
TypeVar bounds or constraints, or when unresolved TypeVars remain after
substitution.
Typical fixes include resolving a compatible closed generic key or tightening
open-generic provider annotations to reflect valid constraints.
"""
[docs]
class DIWireIntegrationError(DIWireError):
"""Signal integration error."""