runtime: Support global unhandled exception handler

Is there any progress on this API? I’d hate for this to miss RC2 since it’s the last API needed to port several applications here (that use our global error handler to monitor the entire network).

I want to throw another +1 for @justinvp’s proposal above, though Exception seems too redundant in the namespace, type, and each event. I’d shorten the event names to remove the suffix, e.g. just Unhandled:

namespace System.Runtime.ExceptionServices
{
    public static class ExceptionEvents
    {
        public static event EventHandler<UnhandledExceptionEventArgs> Unhandled;
    }

    public class UnhandledExceptionEventArgs : EventArgs
    {
        public UnhandledExceptionEventArgs(object exception, bool isTerminating);
        public object ExceptionObject { get; }
        public bool IsTerminating { get; }
    }
}

This means the usage becomes:

ExceptionEvents.Unhandled += (o, args) => {};

@stephentoub I think the former meets almost all reasonable needs. I’m not sure how you’d possibly handle the latter - a global “recover from anything” scenario seems a bit on the insane side to me. I agree on staying away from attempting anything like that.

I’m looking forward to this one personally because of StackExchange.Exceptional - we want to log all errors that are encountered and hopefully developers can hook up such functionality in a very trivial way (as they can today).

Adding back just AppDomain.CurrentDomain.UnhandledException is off the table?

The proposed API doesn’t appear to allow the handler to be asynchronous or otherwise delay the impending termination. Given that the IO operations are all asynchronous, and that most use cases of this API would involve logging it somewhere, is that going to be an issue? Or is the intent that handlers would block on asynchronous IO APIs?

This has been labelled 1.0.0-rtm, @terrajobst any chance we can get this into RC2?

What do folks think about AppContext.UnhandledException? We’ve already moved other things you used to do via AppDomain.CurrentDomain there.

I agree with not bringing back AppDomain for this - it’s both confusing and incorrect. This is a process-level event handler, not an “app domain” one, since that level of containment no longer exists.

We are avoiding re-introducing System.AppDomain because AppDomains are not a concept in .NET Core.

I understand the desire – I’m just wondering if it’d be more practical (both for implementing it and for developers porting existing code to .NET Core already familiar with the existing API) to just expose the existing API (without adding back any other APIs on AppDomain). Its existence in .NET Core could be explained as “there’s only ever a single AppDomain, the current one”.