Internal exceptions being thrown

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?

[nils-a]

@daveaglick not throwing would be the expectation. I tried to make this clearer in https://github.com/spectreconsole/spectre.console/pull/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 https://github.com/spectreconsole/spectre.console/pull/620.

[daveaglick]

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