Global exception handling

I’m playing around with CoreWCF and like what I see so far. I noticed that logging works out of the box with ILogger. But I’m wondering if there’s a way to create a global exception handler. When throwing an exception from the EchoService class in the sample:

public string Echo(string text)
{
    System.Console.WriteLine($"Received {text} from client!");
    throw new ApplicationException("Oh no from CoreWCF");
    return text;
}

The exception is not logged by CoreWCF. Am I missing something or is there another way to make sure this gets logged? Other log messages logged through ILogger gets logged, why I’m sure that logging is configured correctly.

[mconnew]

I still need to work out how we’re going to approach logging in general. Many people use svctraceviewer so it’s important that however we log, it can be transformed/output into something readable by that. But we need to do it in a cross platform way, and also have an eye to integrating into newer tooling which uses OpenTelemetry. I don’t know if that’s sufficient or whether we need a dual approach, do things the old way and support doing things the new way too. There’s also perf counters in the mix to consider.

The DI stuff I believe is in one of the blog posts. You just do services.AddSingleton<IServiceBehavior, MyBehaviorType>() and it gets picked up by CoreWCF as a behavior automatically. But that’s obviously only a CoreWCF thing. We are working on documentation, but it’s a big task and taking some time. The goal has been to make most things from WCF applicable with the change of a using namespace so it hasn’t been too big of a problem, but we do have some areas where we need new docs like DI capabilities. I have some ideas to make DI easier to handle too, to enable things to be scoped per service.

In this case, the DI injectability is really useful as it enables you to inject an ILogger into your IErrorHandler (via your behavior) really easily. We are working on a samples repo similar to the old WCF samples and a sample IErrorHandler would make a good addition. Were you hinting at asking me to write an example using IErrorHandler?

[mconnew]

I want to go a step further and have a method which looks something like this:

public static IServiceCollection AddServiceBehavior<TService, TBehavior>(this IServiceCollection services)
    where TBehavior : IServiceBehavior { }

Then under the hood have some other class which is specific TService and acts as a holder for TBehavior. That way you can scope a behavior to a specific service. This will then require another helper method to act against the IServiceProvider to fetch the helper type and get the specific behavior for the service. That extension method would something like this:

public static TBehavior GetServiceBehavior<TService, TBehavior>(this IServiceProvider provider)
    where TBehavior : IServiceBehavior { }

I wouldn’t want to create a helper which adds a service behavior for all services as that has caused a few problems, notably with the WSDL support. It might make sense to have a method where you add it once and each service type gets it’s own instance. So basically a per service singleton. I could see that being useful behavior to do with the extension method signatue you suggested. So calling AddServiceBehavior would require using GetServiceBehavior to get the service for the specific service type and you wouldn’t be able to use the usual GetRequiredService method as it would be wrapped in a wrapped internally. This whole area requires a discussion thread to get everyones thoughts as there are lots of interesting things which could be done, and it’s a grey line for what should be done. For example, you could have a factory AddServiceBehavior method which looks like this:

public static IServiceCollection AddServiceBehavior<TBehavior>(this IServiceCollection, Func<Type, TBehavior> factory) where TBehavior : IServiceBehavior { }

You would pass a factory delegate which is passed a Type object for the service type that is being created and you would instantiate the behavior and do any configuration before returning it. I’ve been thinking about something similar for easily adding message inspectors and other extensibility point, but where you get passed a ServiceEndpoint so you can decide which message inspector type to return (and configure it if needed), or return null if you don’t want to provide one. We could also have it where the delegate returns true or false to specify whether the message inspector (or other extensibility) should be used for the particular endpoint. There’s a lot that we can do, but you don’t want to end up being more confusing by having hundreds of variations.