我承认：我不会为过多的异常处理而烦恼。我知道我应该做更多，但我永远无法思考从哪里开始和在哪里停止。我不是偷懒。离得很远。这是我对异常处理的矛盾心理过度劳累了。似乎即使在最小的应用程序中也有无数个地方可以应用异常处理，并且开始感觉有点矫枉过正。
我已经通过仔细的测试、验证和默默的祈祷，但这是一个等待发生的糟糕的编程事故。
那么，您的异常处理最佳实践是什么？特别是，应该应用异常处理的最明显/最关键的地方在哪里，应该考虑的地方在哪里？
抱歉这个问题含糊不清，但我真的很想一劳永逸地结束这本书。
【问题讨论】：
标签： asp.net exception-handling
Microsoft 的 Patterns & Practices team 很好地将异常管理的最佳实践整合到企业库 Exception Handling Application Block
如果不使用企业库，我强烈建议您阅读他们的文档。 P&P 团队描述了异常处理的常见场景和最佳实践。
为了帮助您入门，我建议您阅读以下文章：
ASP.NET 特定文章：
【讨论】：
异常处理的黄金法则是：
“只捕捉你知道如何处理的东西”
我见过太多的 try-catch 块，其中 catch 只会重新抛出异常。这没有任何价值。仅仅因为您调用了一个可能引发异常的方法，并不意味着您必须处理调用代码中可能出现的异常。让异常沿调用堆栈向上传播到其他知道该做什么的代码通常是完全可以接受的。 在某些情况下，让异常一直传播到用户界面层然后捕获并将消息显示给用户是有效的。可能没有代码最适合知道如何处理这种情况，用户必须决定行动方案。
【讨论】：
我建议您首先添加一个良好的错误页面，该页面捕获所有异常并向用户打印稍微不那么不友好的消息。请务必记录异常的所有可用详细信息并进行修改。让用户知道您已完成此操作，并为他提供返回（可能）有效的页面的链接。
现在，使用该日志来检测应在何处进行特殊异常处理。请记住，除非您打算对异常进行处理，否则捕获异常是没有用的。如果您有上述页面，则在所有数据库操作上单独捕获数据库异常是没有用的，除非您有某种特定方法可以在该特定点恢复。
请记住：唯一比不捕获异常更糟糕的是，捕获它们并且什么都不做。这只会隐藏真正的问题。
【讨论】：
一般而言，可能比 ASP.NET 特定的异常处理更多，但是：
【讨论】：
从全局异常处理程序开始，例如http://code.google.com/p/elmah/。
那么问题就归结为您正在编写什么样的应用程序以及您需要提供什么样的用户体验。用户体验越丰富，您希望提供的异常处理就越好。
例如，考虑一个具有磁盘配额、文件大小限制、图像尺寸限制等的照片托管站点。对于每个错误，您可以简单地返回“发生错误。请重试”。或者你可以进入详细的错误处理：
等等。等等
没有一种适合所有异常处理的方法。
【讨论】：
在最基本的层面上，您应该处理 Global.asax 文件中的 HttpApplication.Error 事件。这应该将发生的任何异常记录到一个地方，以便您可以查看异常的堆栈跟踪。
除了这个基本级别之外，理想情况下，您应该处理知道可以从中恢复的异常 - 例如，如果您希望文件可能被锁定，那么处理 IOException 并将错误报告给用户将是一个好主意.
【讨论】：