Global exception handling

[achobanov]

I'm trying to achieve a global uniform exception handling, as opposed to having to use try-catch blocks everywhere. I've seen the DispatcherUnhandledException event as a suggestion on a WPF-based solution. I've used it like this:

public partial class App : PrismApplication
{

    public App()
    {
        this.DispatcherUnhandledException += this.Application_UnhandledException;
    }

    private void Application_UnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
        var eventAggregator = ServiceProvider.GetService<IEventAggregator>();
        eventAggregator.GetEvent<ErrorEvent>().Publish(e.Exception.Message);
        e.Handled = true;
    }
...
}

However that does not seem to work. My exception is thrown in the Main Thread, as can be seen here:

Both - ViewModel and exception throw happen on the same thread.

Is there something else that I need to to in the context of Prism to make this work?

[sigmarsson]

Don't do it. Handle the respective exceptions inside their context. You can even introduce your own Trace Listener to track events.

The Global one shall be your very last resort.

[achobanov]

Care to elaborate? Centralised handling of exceptions is a very good way to structure validations and fault-handling. Traces may can account for logging, but I don't see how it is better for my application to perform ui actions (as redirecting to an error view) based on traces is better than a simple global exception handling. Even if it's possible (haven't used them myself) it sounds wrong to me. Handling custom exception globally on the other hand is semantically clean and effective

[brianlagunas]

Just so we are all on the same page, this has nothing to do with Prism.

These are some events you may want to handle to capture errors within you WPF application:

• Dispatcher.UnhandledException
• Application.DispatcherUnhandledException
• AppDomain.UnhandledException
• TaskScheduler.UnobservedTaskException

[achobanov]

Could you please point me to an article or something that goes in depth as to why it is a bad idea? I'm coming from a web background, mostly on .net 4.7, Core and 5. Having global Exception handling is the go-to for validation and/or uniform responses. All I am trying to do is have a single place where I'm handling my custom-made exceptions.

[brianlagunas]

A common handler is different than trying to have a global event. Seems you have some research to do :)

[achobanov]

Yea, I know. Common handling is having a piece of code that handles exceptions in an uniform way. Using global event is a means to run this code, without having to call HandleException(() => action()); on any line that is expected to throw exceptions. W/E, I would love to be able to spend a whole week on this topic, but I've already have a solution, albeit not a pretty one, and I'll roll with it.

[damonpkuml]

Can you show your solution ? It will be very helpfull to me .

[achobanov]

@damonpkuml I'm sorry to say I still don't have a clean solution for UI frameworks. I was surprized that the same issue creeps into Blazor as well, although they do have an ErrorBoundary component which handles some expcetions, but not all (I don't know why). I'm puzzled to this day as to why UI frameworks don't seem to include this functionality. Unfortunately both @brianlagunas and @sigmarsson above don't contribute to a useful extent.

My solution (for UI frameworks) is to essentially wrap every call at the *Behind level within a Action or Func and then execute those delegate types in a try-catch block. You can see the current solution I'm using for Prism and a sample usage. Keep in mind this repo is legacy. I've done a bit better in my Blazor project with SafeHelper, but it's essentially the same thing.