在大型 C# WPF 应用程序中处理未处理的例外: 咨询-allqahome-开发者的问答家园

English 中文(简体)

在大型 C# WPF 应用程序中处理未处理的例外: 咨询

原标题：Handling Unhandled Exceptions in a Large C# WPF Application: Seeking Advice

I’m currently working on a large Windows desktop application built with C# and WPF. We’ve been facing an ongoing issue where, in some releases, we miss adding exception handlers in certain places, leading to unhandled exceptions and, consequently, application crashes. This has sparked some debate within our team. Some colleagues blame the QA team for not catching these cases, while others see it as a developer oversight. Personally, I think both perspectives have merit, but we need a more robust software solution to prevent minor exceptions from crashing the app. To address this, I’m advocating for implementing a global exception handler coupled with a telemetry system (like Sentry). The goal is to catch unhandled exceptions, log them for monitoring, and prevent the application from crashing. This would help us track issues and improve stability over time. However, there’s opposition from some team members. Their concerns are: Catching exceptions globally might lead to the application functioning incorrectly (e.g., dialogs not showing or buttons not working). The application state could become inconsistent if we catch an exception globally and allow the app to continue running. I’m curious to hear about your experiences and insights on this matter. What approaches have you found effective in dealing with unhandled exceptions? How do you balance error handling and application stability in large desktop applications? Thanks for your input!

问题回答

Much of this advice is not unqiue to WPF, but I employ a fairly simple Result pattern combined with an ICommand-based exception handling scheme. Result Pattern First, I have a Result and Result class that must always be returned whenever there is a possibility of a method failing. A simplified version: public class Result { public Result( string? error = null, string? warning = null, Exception? ex = null) { if (!string.IsNullOrEmpty(error) || ex != null) { this.Error = error; this.InnerException = ex; LogError?.Invoke(this, this); IsSuccess = false; } else { this.IsSuccess = true; } } public void Throw() { if (this.InnerException != null) throw this.InnerException; else if (!string.IsNullOrEmpty(this.Error)) throw new Exception(this.Error); } public bool IsSuccess { get; } public string? Error { get; } public string? Warning { get; } public Exception? InnerException { get; } // For global logging public static event EventHandler? LogError; public static event EventHandler? LogWarning; // For the (hopefully) 99% case public static readonly Result Success = new Result(); // Allows you to just return the Exception directly public static implicit operator Result(Exception ex) { return new Result(ex: ex); } } public class Result : Result { public Result(T value, string? warning = null) : base(null, warning, null) { this.Value = value; } public Result(string? error = null, Exception? ex = null) :base(error, null, ex) { } T? _Value; public T? Value { get { if (!this.IsSuccess) // This prevents us from accidentally using // the value if we neglected to check for // failure. this.Throw(); return _Value; } private set { _Value = value; } } // These simplify usage (returning values, etc.) public static implicit operator T? (Result result) { return result.Value; } public static implicit operator Result(T value) { return new Result(value); } public static implicit operator Result(Exception ex) { return new Result(ex: ex); } } Here s what it looks like in action: public static Result Divide(double a, double b) { if (b == 0) return new Result("Division by zero"); try { // can just return value thanks to implicit cast return a / b; } catch (Exception ex) { // ditto return ex; } } public static void CheckResult() { var r = Divide(1, 2); if (!r.IsSuccess) r.Throw(); var r2 = Divide(2, 0); if (r2.Value > 1) { // Oops, forgot to check for failure! Plain old // exception will then be thrown. } } Or a more practical example: public static Result SafeFileOpen(string path) { try { return File.OpenRead(path); } catch (Exception ex) { return ex; } } In my opinion, .NET is way too Exception crazed. Both corelib and third party libraries will throw exceptions for all kinds of unpredictable and inconsistent reasons, very often for things that are irrelevant or easily recovered from. That s why I employ the Result pattern in every single solitary bit of my code that could possibly fail, and wrap every call to code that I didn t write in an Exception handler that returns the Result-wrapped exception. Then my code can decide what to do. ICommand-based Error Handling The second prong of this approach is mostly relevant if you re using the MVVM pattern, so feel free to stop here if not. I implement my own ICommand class that wraps every Action in an exception handler while also making use of the Result pattern: public class Command : ICommand, INotifyPropertyChanged { private Func _action; public event EventHandler? CanExecuteChanged; public event PropertyChangedEventHandler? PropertyChanged; public Command(Func action) { this._action = action; } // You can bind this to a UI element that will display // the error. A subclassed Button with a textblock beneath // it would work great for this. string? _Error; public string? Error { get { return _Error; } set { if (_Error == value) return; _Error = value; PropertyChanged?.Invoke( this, new PropertyChangedEventArgs(nameof(Error))); } } public void Execute(object? parameter) { Result r; try { this.Error = null; r = this._action(parameter is T tparam ? tparam : default(T)); } catch (Exception ex) { r = new Result(ex: ex); } if (!r.IsSuccess) { this.Error = r.Error ?? r.InnerException?.Message; } } public bool CanExecute(object? parameter) { return true; } } public class Command : Command