System.Composition: CompositionContext.TryGetExport throws CompositionFailedException

[davidmilligan]

The CompositionContext.TryGetExport method can throw a CompositionFailedException. This violates the common convention/expectation that TryXXX methods don't throw, instead they just return false.

I would expect that calling GetExport would throw an exception in this situation but I would expect that TryGetExport would simply return false.

Stack Trace:

An exception of type 'System.Composition.Hosting.CompositionFailedException' occurred in System.Composition.Hosting.dll but was not handled in user code: 'The component (unknown) cannot be created outside the Scoped sharing boundary.'
   at System.Composition.Hosting.Core.LifetimeContext.FindContextWithin(String sharingBoundary)
   at System.Composition.TypedParts.ActivationFeatures.LifetimeFeature.<>c__DisplayClass1_0.<RewriteActivator>b__0(LifetimeContext c, CompositionOperation o)
   at System.Composition.Hosting.Core.CompositionOperation.Run(LifetimeContext outermostLifetimeContext, CompositeActivator compositionRootActivator)
   at System.Composition.Hosting.Core.LifetimeContext.TryGetExport(CompositionContract contract, Object& export)
   at System.Composition.CompositionContext.TryGetExport(Type exportType, String contractName, Object& export)
   at System.Composition.CompositionContext.TryGetExport(Type exportType, Object& export)

[danmoseley]

I assume the same thing happens on.NET Framework?

You may well be right that this should not throw, but note that the Try pattern does not imply that all exceptions are caught. Just the type(s) that are potentially on the normal, recoverable path (I don't have the book in front of me to quote the actual language).

I don’t know this API so I can't say whether that would include this type.

[am11]

Just the type(s) that are potentially on the normal, recoverable path

If it is deterministic, can these rules be objectified in terms of a static analyzer?

[davidmilligan]

Well this is the sort of error I would expect to be caught and return false. Yes I agree that TryXXX doesn’t imply that every single type of exception be caught (e.g. OutOfMemoryException), but in this particular situation I simply passed a Type to the TryGetExport that I’m not allowed to get an instance of due to sharing boundary constraints. It’s not really an “exceptional” situation. I just passed some invalid input. Exactly the sort of situation I would expect to just return false. What if I’m simply probing the container to see if I’m allowed to get an export of various types based on sharing boundary? I have to put a try/catch around a call to TryGetExport and take the perf hit? That’s far from ideal.

[davidmilligan]

I came across this issue while I was writing an adapter to use System.Composition with Asp.Net Core's DI framework. The repo is here: https://github.com/davidmilligan/System.Composition.Extensions.DependencyInjection

In particular see DependencyInjectionProvider line 30.

I'm currently using a workaround that checks the sharing boundary by calling ToString on the container and comparing it with the string "Root Lifetime Context", but this just feels wrong. I should just be able to just write this instead (but the following results in the exception):

object export;
if ((c.TryGetExport(typeof(MefServiceScopeFallback), out export)
    || c.TryGetExport(typeof(MefServiceRootFallback), out export))
    && export is IMefServiceFallback serviceProvider)
{

What this code is trying to do is: if the context is not the root context, getting the scoped service should fail, so then I'll try to get the root service instead. That way, if this code is given a scoped context it will retrieve the scoped service, otherwise it was given the root context so it will try to get a root (globally shared) service.

[ericstj]

Even Try Methods can throw. The distinction is usually if the exception is caused by a design time error or a runtime error. Typically these methods still throw for design time errors (eg: you called the method wrong, provided incorrect parameters that aren't runtime data, or setup the method wrong). It's important to still throw in these cases so you don't hide a deisgn-time error.

Would you classify this case as a design time error? I couldn't tell from the OP since it omitted repro steps.

[davidmilligan]

No, this is not a design time error. I’ve already provided plenty of justification as to why in my comments above, as this question was already asked in this thread. There’s also repro steps in an above comment.