Using TryResolve instead of Resolve with Autofac

[StanleyGoldman]

What kind of change does this PR introduce?
Fixing AutofacDependencyResolver so it does not throw, catch and swallow exceptions while resolving services.

What is the current behavior?
I'm currently using AutofacDependencyResolver with ViewModelViewHost in a ListView and noticed the massive lag while debugging and the bloat of ComponentNotRegisteredExceptions being thrown even though my code works.

What is the new behavior?
The new behavior should be the same, except faster when using Autofac and debugging.

What might this PR break?
Nothing I can think of.

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

[dnfclas]

All CLA requirements met.

[glennawatson]

I think @RLittlesII wanted to give some feedback on this PR so hold on before merging.

[dpvreony]

gah that poped up right as I did it :(

[glennawatson]

Ah well, I'm sure @RLittlesII can put the feedback and provide another PR if necessary.

[RLittlesII]

@glennawatson @dpvreony

I was honestly wondering if the performance issue was because the exception is thrown.

The documentation states that TryResolve will still throw the DependencyResolutionException so I am not sure this change will actually resolve the issue.

Both ResolveOptional() and TryResolve() revolve around the conditional nature of a specific service being registered. If the service is registered, resolution will be attempted. If resolution fails (e.g., due to lack of a dependency being registered), you will still get a DependencyResolutionException. If you need conditional resolution around a service where the condition is based on whether or not the service can successfully resolve, wrap the Resolve() call with a try/catch block.

https://autofaccn.readthedocs.io/en/latest/resolve/

Resolving Services — Autofac 4.0 documentation

[StanleyGoldman]

I keep on re-reading it and I feel like the part of the documentation contradicts what was stated and demonstrated in the section right above it...

// If IService is registered, it will be resolved; if
// it isn't registered, the return value will be null.
var service = scope.ResolveOptional<IService>();

// If IProvider is registered, the provider variable
// will hold the value; otherwise you can take some
// other action.
IProvider provider = null;
if(scope.TryResolve<IProvider>(out provider))
{
  // Do something with the resolved provider value.
}

[StanleyGoldman]

Nope, I think I understand what the documentation is saying..
The document is saying that if you think the "construction" is going to fail, you will still need to try/catch
"construction" != "resolution"