-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Exception Logging on .NET MAUI Apps
It is a good idea to monitor the health of your deployed MAUI apps for performance and crashes. Somme tools exists for that. In this document, we'll talk about the various exception being thrown, resulting to app crashes or not, what to log and ideally how to act on it.
This document is a work-in-progress, feel free to suggest edits. Thanks.
AppDomain.CurrentDomain.UnhandledException event is triggered when an exception is thrown and unhandled. You get a chance to log it, but the application will crash right after that. DO log those exceptions.
As of .NET10, iOS and MacOS should aggregate all those exception through that event, and it's the main point for collection (see https://github.com/dotnet/macios/issues/15252 for tracking the effort)
All should go through AppDomain.CurrentDomain.UnhandledException
Exceptions on background threads triggers an AppDomain.CurrentDomain.UnhandledException event. App exceptions triggers a Microsoft.UI.Xaml.Application.Current.UnhandledException.
DO listen to both, and log both.
-
AppDomain.CurrentDomain.FirstChanceException
DO NOT subscribe to those or log this on deployed application. use it for debugging purposes only. This is fired for every exception, at any level, caught or not. -
TaskScheduler.UnobservedTaskException
is fired when an exception happens on an asynchronous/await task. This a chance to toObserve
it, and avoid the escalation toAppDomain.CurrentDomain.UnhandledException
. Only subscribe to this if you have the intent of acting on some exception, and know that you can recover (handle network errors, etc...). If you don't plan to handle the exception, let it bubble up. - [iOS]
ObjCRuntime.Runtime.MarshalManagedException
exceptional exception. Should almost never happen. DO log them, act on it. It might or might not crash the application. - [Android]
Android.Runtime.AndroidEnvironment.UnhandledExceptionRaiser
isn't meant for general consumption.