Internal exceptions being thrown

[daveaglick]

I updated Spectre.Console and started seeing handled exceptions being thrown, got curious, and traced it back to PR #376. The problem is that while the new try/catch introduced in this PR around the resolver.Resolve(settingsType) call works, it ends up creating an expected control flow where throwing is "normal". That's fine as far as it goes, but it does result in unnecessary exceptions under the hood which will both impact performance (though likely not in any critical way) and trigger exception filters when debugging. And it feels icky :)

The reason I didn't see these exceptions before the update was because TypeRegistrarExtensions.RegisterDependencies() was registering the settings types in my container for me, so when the old code asked the container for them, they were already in there. That code was removed in this PR so the container doesn't have the settings type registered any more.

It's unclear whether this is a "problem" that needs solving. I generally don't love throwing exceptions during expected flows, even if I'm catching them. If there's an interest in changing the behavior the best thing I can think of is to introduce an ITypeResolver.TryResolve() that can return a null value for unregistered types without throwing (or alternatively use a bool/out pattern). Then use that to resolve the settings type without a try/catch and fallback to direct instantiation if it returns null.

Would you be interested in a PR for this or should the behavior be considered by design?

[patriksvensson]

@daveaglick I would want us to do the right thing here, so a PR would be appreciated!

[daveaglick]

Will do! Shouldn't be a tough one (famous last words). I may not have a chance to open a PR until Friday for...errr...reasons...

👀

[nils-a]

@daveaglick you're still working on this one? (I mean, there's still a day left in your self-chosen timeframe, so I wouldn't want to put any pressure on you. 😬)

[daveaglick]

Lol. I like to live on the edge. Nothing like a little pressure!

[daveaglick]

I was all set to implement this as described (only two months later, nbd!) but after digging in, realized that maybe this is just a documentation issue. Consider this code I found in CommandConstructorBinder:

var value = resolver.Resolve(parameter.ParameterType);
if (value == null)
{
    throw CommandRuntimeException.CouldNotResolveType(parameter.ParameterType);
}

That strongly suggests that the expected behavior of ITypeResolver.Resolve() should be to return null when the type cannot be resolved. Compare that to the code I was originally looking at in CommandPropertyBinder:

try
{
    if (resolver.Resolve(settingsType) is CommandSettings settings)
    {
        return settings;
    }
}
catch
{
    // ignored
}

That code has a try/catch guard, suggesting ITypeResolver.Resolve() could throw.

So my question is this: should ITypeResolver.Resolve() work more like the .NET IServiceProvider.GetRequiredService() and guarantee a result or it's an exception or should it work more like IServiceProvider.GetService() and return a null result when the type can't be resolved?

I had assumed the former and implemented my own ITypeResolver that way, which is why it was throwing here. However, if the intent is the latter, then it's my implementation that's wrong and we probably just need to document that better (and remove the try/catch in CommandPropertyBinder because if that's the case then an exception here really is an unexpected exception).

[nils-a]

@daveaglick not throwing would be the expectation. I tried to make this clearer in #620.
I also added the TypeRegistrarBaseTest in Spectre.Console.Testing that can be used by someone implementing an ITypeRegistrar/ ITypeResolver to verify some base expectations of these two.

Closed in #620.

[daveaglick]

Looks great, thanks!