Closed oleksabor closed 4 years ago
I've found that public bool ServiceGraph.CouldBuild(Type concreteType)
calls the public ConstructorInfo ConstructorInstance<T>.DetermineConstructor(ServiceGraph services, out string message)
and there is error properly formed.
Cannot fill the dependencies of any of the public constructors Available constructors:new Bug_204_registration_error_misses_original_reason.AnotherImpl(Bug_204_registration_error_misses_original_reason.IInversion pl) *Bug_204_registration_error_misses_original_reason.IInversion is not registered within this container and cannot be auto discovered by any missing family policy
However message
variable value stays in the ServiceGraph.CouldBuild
and never used any more.
Exception is raised in the public object Scope.GetInstance(Type serviceType)
that is not aware about the original reason.
The simplest way is to throw the exception from the ConstructorInstance<T>.DetermineConstructor
However I'm afraid that this can break legacy logic that handles instance creation errors with if ( != null)
checks.
Does it have sense to add new ServiceGraph
property that will hold the ConstructorInstance<T>.DetermineConstructor
error?
Then new property can be used when Scope.GetInstance
raises exception, like
public class ServiceGraph : IDisposable
{
public string CouldBuildError {get; protected set;}
public bool CouldBuild(Type concreteType)
{
var constructorInstance = new ConstructorInstance(concreteType, concreteType, ServiceLifetime.Transient);
foreach (var policy in InstancePolicies)
{
policy.Apply(constructorInstance);
}
var ctor = constructorInstance.DetermineConstructor(this, out string message);
CouldBuildErrror = message;
return ctor != null && message.IsEmpty();
}
}
public class Scope : IServiceContext
// ENDSAMPLE
{
public object GetInstance(Type serviceType)
{
assertNotDisposed();
var resolver = ServiceGraph.FindResolver(serviceType);
if (resolver == null)
{
throw new LamarMissingRegistrationException(ServiceGraph.CouldBuildError, serviceType);
}
return resolver(this);
}
}
The only one problem I see is multi threading issue if ServiceGraph
instance is shared between several Scope
(public Scope(ServiceGraph serviceGraph, Scope root)
)
@oleksabor Good idea, and done. Just a wee bit different than what you suggested. This will be in Lamar 4.1 by early next week.
Hi
Please help me how to get the error origin in case if Lamar (4.0.0) Container can not resolve the dependency:
interface_resolved
fails becauseInversion2
class name does not match to the interface name. The error message is ok and I understand what to do:another_not_null
fails with error message:This message does not contain the error origin and I do not know why it fails.
The same is for the
some_not_null
Is there a chance to get the
IInversion
interface name in the error message for bothsome_not_null
andanother_not_null
cases ?The exception VS test output looks like:
There is no inner exception to get missing interface registration info unfortunately
Regards.