我承认：我不打扰太多异常处理。我知道我应该做更多的事情，但我永远无法把头围绕在哪里开始和停止。我不懒惰。离得很远。就是因为异常处理矛盾而过度劳累。看起来，即使是最小的应用程序中，可以应用异常处理的地方似乎也有无数个地方，并且可能开始感觉过度杀伤。.net网络应用程序中的异常处理
我已经通过了仔细的测试，验证和沉默的祈祷，但这是一个不好的编程事故等待发生。
那么，您的异常处理最佳实践是什么？特别是，应该应用异常处理的最明显/关键的地方在哪里，以及应该考虑哪些地方？
对不起，这个问题含糊不清，但我真的很想关闭这本书，一劳永逸。
微软Patterns & Practices team确实包含异常管理的最佳实践做好进入企业库Exception Handling Application Block
事件，如果不会使用企业库，我强烈建议您阅读他们的文档。 P团队描述了异常处理的常见场景和最佳实践。
为了让您一开始我推荐阅读以下文章：
ASP.NET具体条款：
嗯，你应该处理在Global.asax文件中HttpApplication.Error事件非常基本的水平。这应该记录发生在单个位置的任何异常，以便您可以查看异常的堆栈跟踪。
除了这个基本级别，你应该理想地处理异常，你知道你可以从中恢复 - 例如，如果你期望一个文件可能被锁定，那么处理IOException并将错误报告给用户将是一件好事理念。
我建议你从添加一个良好的错误页面开始，捕获所有异常并向用户输出一个稍微不友好的消息。务必记录所有可用的例外情况并修改。让用户知道你已经完成了这个工作，并给他一个链接回到一个可能（可能）工作的页面。
现在，使用该日志来检测应该将特殊异常处理置于何处。请记住，捕捉异常是没有用的，除非你打算对它做些什么。如果你有上述页面，那么在所有数据库操作中单独捕获数据库异常是没有用的，除非你有特定的方法来恢复这个特定的点。
记住：唯一比不捕捉异常更糟糕的是抓住它们，而不是无所事事。这只会掩盖真正的问题。
与异常处理的金科玉律是：
“只有抓住你知道如何处理”
我见过太多的try-catch块，其中抓什么也不做，但重新抛出异常。这没有增加任何价值。仅仅因为你调用了一个有可能引发异常的方法并不意味着你必须处理调用代码中可能出现的异常。让异常在调用堆栈中传播给其他确实知道该做什么的代码通常是完全可以接受的。 在某些情况下，让异常一直传播到用户界面层，然后捕获并向用户显示消息是有效的。这可能是因为没有代码是最适合知道如何处理这种情况的，用户必须决定行动的过程。
可能是更多的异常处理一般比ASP.NET上特有的，但是：
从全局异常处理程序开始，如http://code.google.com/p/elmah/。
然后问题归结为您要写什么类型的应用程序以及您需要提供哪种用户体验。用户体验越丰富，您希望提供更好的异常处理。
作为一个例子，考虑有磁盘配额，文件大小限制，图片尺寸限制等的照片托管站点。对于每个错误，您可以简单地返回“发生错误，请重试”。或者你可以进入详细的错误处理：
等等，等等
没有一个放之四海而皆准的异常处理。
是的，有一段时间我想迫使开发伙伴们将它写100次在白板上，除非他们停止写入catch（Exception）{} :-) – aku 2008-09-11 08:04:15