.NET中捕获System.Exception是否属于不良编程实践？

结论先行：和Java中捕获java.lang.Throwable的原则类似，在.NET中直接捕获System.Exception通常是不推荐的做法，但存在少数合理的例外场景。

为什么不推荐直接捕获System.Exception？ #

• 掩盖致命问题：System.Exception包含了诸如OutOfMemoryException、StackOverflowException这类致命异常，捕获它们会让程序在不稳定的状态下继续运行，可能引发数据损坏、进程崩溃等更严重的后果。
• 丢失错误语义：.NET的异常体系设计是为了区分不同类型的错误（比如ArgumentNullException对应参数错误，IOException对应IO操作失败），直接捕获根异常会让你失去针对性处理的机会，无法根据错误类型执行正确的恢复逻辑。
• 增加调试难度：当所有异常被统一捕获时，你很难定位到具体的错误来源，排查问题时会陷入“到处都是异常捕获，却不知道哪里出了问题”的困境。

哪些场景可以合理捕获System.Exception？ #

• 全局异常处理：比如在桌面应用的AppDomain.UnhandledException事件、ASP.NET Core的全局异常中间件中，捕获所有异常是为了记录详细日志、给用户展示友好提示，而非让程序继续执行。
• 框架级封装：如果你在开发通用框架，需要将第三方库抛出的各种未明确声明的异常，转换为框架自定义的异常类型，这时可以捕获System.Exception，但必须重新抛出或包装，不能直接吞掉异常。
• 可控的第三方调用边界：调用一个文档不完善、可能抛出任意异常的第三方库时，可以在调用边界捕获System.Exception，记录日志后优雅降级，但要注意过滤掉致命异常，避免程序带病运行。

正确的异常处理示例 #

优先捕获具体异常类型，而非根异常：

try
{
    var content = File.ReadAllText("config.json");
}
catch (FileNotFoundException ex)
{
    // 针对性处理文件不存在的情况
    Console.WriteLine($"配置文件缺失：{ex.FileName}");
}
catch (IOException ex)
{
    // 处理IO相关错误
    Console.WriteLine($"读取配置文件失败：{ex.Message}");
}

内容的提问来源于stack exchange，提问作者zhoudu