8

我承认：我不为过多的异常处理而烦恼。我知道我应该做更多，但我永远无法思考从哪里开始和在哪里停止。我不是偷懒。离得很远。这是我对异常处理的矛盾心理过度劳累了。似乎在最小的应用程序中似乎有无数个地方可以应用异常处理，并且开始感觉像是矫枉过正。

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

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

抱歉这个问题含糊不清，但我真的很想一劳永逸地结束这本书。

4

6 回答 6

11

Microsoft 的模式和实践团队在将异常管理的最佳实践整合到企业库异常处理应用程序块中做得很好

如果不使用 Enterprise Library，我强烈建议您阅读他们的文档。P&P 团队描述了异常处理的常见场景和最佳实践。

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

ASP.NET 特定文章：

于 2008-09-11T07:49:00.840 回答
7

异常处理的黄金法则是：

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

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

于 2008-09-11T08:01:52.433 回答
2

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

现在，使用该日志来检测应该在哪里进行特殊异常处理。请记住，除非您打算对异常进行处理，否则捕获异常是没有用的。如果您有上述页面，则在所有数据库操作上单独捕获数据库异常是没有用的，除非您有某种特定的方法可以在该特定点恢复。

请记住：唯一比不捕获异常更糟糕的是，捕获它们并且什么都不做。这只会隐藏真正的问题。

于 2008-09-11T07:53:27.820 回答
1

一般而言，可能比 ASP.NET 特定的异常处理更多，但是：

  • 尝试捕获尽可能接近原因的异常，以便您可以记录（记录）尽可能多的有关异常的信息。
  • 在程序的入口点包含某种形式的包罗万象、最后手段的异常处理程序。在 ASP.NET 中，这可能是应用程序级别的错误处理程序。
  • 如果您不知道如何“正确”处理异常，请让它冒泡到 catch all 处理程序，您可以将其视为“意外”异常。
  • 将 .NET 中的 Try***** 方法用于访问字典等操作。如果您在一个循环中抛出多个异常，这有助于避免主要的性能问题（异常处理相对较慢）。
  • 不要使用异常处理来控制程序的正常逻辑，例如通过 throw 语句退出循环。
于 2008-09-11T08:03:20.917 回答
1

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

那么问题就归结为您正在编写什么样的应用程序以及您需要提供什么样的用户体验。用户体验越丰富，您想要提供的异常处理就越好。

例如，考虑一个具有磁盘配额、文件大小限制、图像尺寸限制等的照片托管站点。对于每个错误，您可以简单地返回“发生错误。请重试”。或者您可以进行详细的错误处理：

  • “您的文件太大。最大文件大小为 5mb。”
  • “你的图片太大了。最大尺寸为 1200x1200。”
  • “您的相册已满。最大存储容量为 1GB”。
  • “您的上传出错。我们的仓鼠不高兴。请稍后再回来。”

等等等等

没有一种适合所有异常处理的方法。

于 2008-10-23T17:23:39.540 回答
0

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

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

于 2008-09-11T07:49:35.957 回答