.net网络应用中的异常处理

Question

我承认：我没有太多的异常处理。我知道我应该做得更多，但我永远不能把头包裹在哪里开始和停在哪里。我不是很懒。离得很远。这就是我对异常处理的矛盾心理过度紧张。看起来即使是最小的应用程序中也存在看似无限多的地方，可以应用异常处理，并且它可能开始感觉有点过分。

我经过仔细的测试，验证和默祷，但这是一个糟糕的编程事故等待发生。

那么，您的异常处理最佳实践是什么？特别是，应该应用异常处理的最明显/最关键的地方在哪里？应该考虑哪些地方？

对不起这个问题含糊其辞，但我真的想一劳永逸地关闭这本书。

Answer 1

Microsoft Patterns & Practices team将异常管理的最佳实践纳入企业库Exception Handling Application Block

做得很好

如果不使用企业库，我高度建议您阅读他们的文档。 P＆amp; P团队描述了异常处理的常见场景和最佳实践。

为了让您入门，我建议您阅读以下文章：

MSDN上的
• Exception Handling
MSDN上的
• Exception Management in .NET
CodeProject上的
• Exception Handling Best Practices in .NET

ASP.NET特定文章：

• User Friendly ASP.NET Exception Handling
• Global Exception Handling with ASP.NET
• Exception handling in C# and ASP .Net

Answer 2

具有异常处理的黄金法则是：

  

“只抓住你知道如何处理”

我见过太多的try-catch块，其中catch只会重新抛出异常。这没有增加价值。仅仅因为你调用一个有可能抛出异常的方法并不意味着你必须处理调用代码中可能的异常。让异常在调用堆栈中传播到其他知道该做什么的代码通常是完全可以接受的。 在某些情况下，允许异常一直传播到用户界面层然后捕获并向用户显示消息是有效的。可能没有代码最适合知道如何处理这种情况，用户必须决定行动方案。

Answer 3

我建议您首先添加一个能够捕获所有异常并向用户打印稍微不友好的消息的错误页面。请务必记录异常的所有可用详细信息并进行修改。让用户知道你已经完成了这个，并给他一个链接回到一个可能（可能）工作的页面。

现在，使用该日志来检测应该放置特殊异常处理的位置。请记住，除非您计划对其进行操作，否则捕获异常没有用处。如果您具有上述页面，则无法在所有数据库操作上单独捕获数据库异常，除非您有特定的方法在该特定点恢复。

记住：唯一比没有捕获异常更糟糕的事情就是抓住它们而不是什么都不做。这只会隐藏真正的问题。

Answer 4

可能更多关于异常处理，而不是ASP.NET特色，但是：

• 尝试捕捉异常接近 尽可能让你的事业 可以记录（日志）尽可能多的信息 关于例外情况。
• 包括某种形式的捕获，最后 度假村的异常处理程序 您的计划的入口点。在 ASP.NET可能就是这样 应用级错误处理程序。
• 如果您不知道如何“正确”处理异常，请将其冒泡到catch all处理程序，您可以将其视为“意外”异常。
• 在.NET中使用Try *****方法 对于像访问一样的东西 字典。这有助于避免重大 性能问题（例外 处理相对较慢）如果你 在a中抛出多个异常 循环。
• 不要使用异常处理 控制你的正常逻辑 程序，例如退出循环通过 抛出声明。

Answer 5

从全局异常处理程序开始，例如http://code.google.com/p/elmah/。

然后问题归结为你在写什么样的应用程序以及你需要提供什么样的用户体验。用户体验越丰富，您希望提供更好的异常处理。

作为示例，请考虑照片托管网站，其中包含磁盘配额，文件大小限制，图像尺寸限制等。对于每个错误，您只需返回“发生错误。请再试一次”。或者你可以进入详细的错误处理：

• “你的档案很大。最大 filesizes是5mb。“
• “你的形象是 到大。最大尺寸是 1200x1200。“
• “你的相册已满。 最大存储容量为1GB“。
• “你的错误 上传。我们的妓女不高兴。 请稍后再来。“

等。等

没有一种尺寸可以用于异常处理。

Answer 6

在最基本的层面上，您应该处理Global.asax文件中的HttpApplication.Error事件。这应记录发生在单个位置的任何异常，以便您可以查看异常的堆栈跟踪。

除了这个基本级别之外，理想情况下应该处理您知道可以从中恢复的异常 - 例如，如果您希望文件可能被锁定，那么处理IOException并将错误报告给用户将是一个好主意