What's the intended behavior of a faulty singleton?

[yallie]

Hello @dadhi,

Consider a singleton service that failed to initialize when it was first resolved.
What's the intended behavior on subsequent resolutions?

1. Should it rethrow the same exception every time it's resolved again?
2. Or should it rather retry its initialization (and if it succeeds, it's instance stays cached in the container)?

[dadhi]

hi @yallie
Good question, I think it was asked long ago but I forgot the conclusion.
Definitely its expression won't be cached, I remember the code for preventing it. So you may modify registrations later to resolve the problem. At least it was the intent.

[yallie]

Definitely its expression won't be cached, I remember the code for preventing it.
So you may modify registrations later to resolve the problem. At least it was the intent.

Great, I would definitely prefer this behavior!
An application would have a chance to recover from the first faulty singleton initialization.

But it looks like the expression (or a delegate?) is cached. Pull request demo: #620.

[yallie]

It's probably thanks to Lazy<T> wrapper exception caching.
Related discussion about this Lazy<T> behavior: dotnet/runtime#27421
The API improvement was proposed in 2018 and is still debated :-\

[dadhi]

Huh, so funny.. so no one interested or likely the .NET team is very small to handle it.
If it is critical for you we may add our own Lazy (maybe reuse the name but change the namespace).
I did not look at the PR yet, so maybe an alternative exist.

[yallie]

Here is a nice alternative implementation:

public class LazyWithRetry<T>
{
    private volatile Lazy<T> _lazy;

    public LazyWithRetry(Func<T> valueFactory)
    {
        ArgumentNullException.ThrowIfNull(valueFactory);
        T GetValue()
        {
            try { return valueFactory(); }
            catch { _lazy = new(GetValue); throw; }
        }
        _lazy = new(GetValue);
    }

    public T Value => _lazy.Value;
}

Too bad Lazy can't be transparently replaced with something like this :-\

[yallie]

If it is critical for you we may add our own Lazy (maybe reuse the name but change the namespace).

No, it's not critical... I think I can eventually replace my lazy imports with an alternative lazy wrapper.
But I like the idea of providing a builtin alternative Lazy implementation without exception caching.
Seems to be a useful addition.

I did not look at the PR yet, so maybe an alternative exist.

Even if we can't change Lazy behavior, the PR demonstrates a few weird exceptions.
Perhaps the diagnostics can be improved?

[yallie]

I have a test with two services using a faulty singleton dependency, one with Lazy wrapper, and another is non-lazy. Both services have a dependency which throws an InvalidOperationException on its first instantiation:

public class ServiceWithLazyImport
{
    [Import]
    private Lazy<IDependency> LazyDependency { get; set; }

    public void DoWork() => LazyDependency.Value.DoWork();
}

public class ServiceWithNormalImport
{
    [Import]
    private IDependency Dependency { get; set; }

    public void DoWork() => Dependency.DoWork();
}

Test code is as follows:

// dependency initialization failed (test passes)
var s1 = container.Resolve<ServiceWithLazyImport>();
Assert.That(() => s1.DoWork(), Throws.TypeOf<InvalidOperationException>());

// should it fail or should it work?
var s2 = container.Resolve<ServiceWithNormalImport>();
s2.DoWork();

// should it fail or should it work?
var s3 = container.Resolve<ServiceWithLazyImport>();
s3.DoWork();

The code above behaves like this.

s2 throws an unexpected exception in RuntimeType.CheckValue:

s3 throws an EntryPointNotFoundException:

Also, I've seen s3 rethrowing (kind of expected) InvalidOperationException but with a weird very long call stack, but couldn't replicate it in my test yet.

[dadhi]

@yallie Ok, I have added the test to the v6-dev branch and see the exceptions, and they are definitely not helping.
Will do something.

[yallie]

Thanks Maksim! 🎉