什么是处理异常以及如何在asp.net中处理它们的最佳方法

Question

首先,我已经熟悉了简单的异常处理语法,但我要问的是最佳位置,最佳时间以及处理它们的最佳方法.

我正在构建一个N层应用程序.所以我认为DAL有时会产生一些错误来处理..而我刚刚了解了SqlException类,该类的处理是什么？我曾经看过一个处理SqlException的代码,然后它处理Exception!

在了解了实践以及我将要处理它们之后,我计划创建一个连接数据库并在数据库中记录错误的方法,以便我可以解决它,但我仍然不知道应该提供哪些信息收集让我识别整个情况!

---

我认为异常处理并不是什么大问题.但我时不时地读到一些奇怪的建议 - 我从未理解 - 在问题评论中但是没有人能回答我,因为这是一些非常古老的问题!

"不要只是明确地捕捉异常"

"应用程序中更高层使用的代码必须始终只抛出异常,而不必担心如何处理它们."

编辑

怎么样的Page_Error事件和Application_Error..我看到他们是处理错误的好习惯

Answer 1

异常处理是一个大问题,为此设计一个好的策略并不简单.

首先,一些一般规则:

• 当正在运行的代码完全无法继续时,会发生异常,因此可能会尝试处理一些内部异常,但最终会失败.想想TCP连接:如果损坏的数据包到达,它是一个例外,但TCP协议可以处理它.如果太多损坏,则抛出I/O或套接字异常
• 无法始终处理例外情况.几乎在所有情况下,当您从底层图层获得异常时,您无法运行更正代码.如果您的应用程序依赖于数据库且处于脱机状态,则当您获得有关它的例外时,您只能显示错误消息
• 例外可能是意料之外的,并且可能揭示设计或实施缺陷.例如,一个实现缺陷可能是你有一个冗余数据库的情况,但是当你连接到第一个镜像时你没有尝试第二个

对于第三点,记录异常并定期分析日志以查找任何奇怪的情况非常重要.那么,让我们从具体的答案开始吧.

首先

想想"处理"异常.当您编写每个代码行时,请考虑可能阻止其完成的可能问题,并考虑可能的纠正措施.如果可能的话.错误消息不是一种好的处理方式,这是最新的策略.

不要开始编写try-catch(Exception),但更喜欢特定的异常.如果你需要将字符串解析为数字等,那么期望FormatException,如果你需要从Object你的类型转换为期望InvalidCastException

编写较低级别的图层时

不要犹豫,抛出异常!不要像许多人那样做,即.return null或者使用(如ANSI C)布尔返回值和引用参数.有例外.如果您可以处理异常(即您没有找到本地文件但是您知道您有远程备份,那么FileNotFoundException通过调用远程镜像处理,但如果您仍然无法连接然后最终抛出),那么执行此操作尝试恢复计算,但如果你不能然后扔.并且不要忘记抛出内部异常(如果存在),因为它有助于登录最高层.

基本上,即使你没有抓到任何东西,你仍然可以决定自己抛出异常!特别是当功能参数无效时,强烈建议这样做!

另一个不错的选择是仍然登录底层.无论发生异常,您实际上都想记录.

当你记录

记得给消息一个足够的严重性.如果您通过代码发现您的数据库处于脱机状态,那么这不是意外的异常.仍然将其记录为错误,但在调查日志时不要担心代码错误.相反,如果您捕获到代码无法识别的异常(这NullReferenceException是一个典型示例),则以最高严重性记录,即.致命的,给予它最大的优先权!

ASP.NET的一个好策略

肯定可以基于Page.OnError方法.如果您的站点的所有页面都有基页类,那么您绝对应该覆盖该方法.在该方法中,您应该首先记录您的异常.

您也不应该滥用try-catch(异常)块,因为如果您没有捕获异常,则无法使用catch处理,您将不得不通过OnError处理它.

当你运行这样的方法时,不要马上考虑Server.RemoveError().您可能更喜欢为HTTP 500错误(当未处理的异常冒泡到ASP.NET运行时时触发)的静态HTML页面向用户显示礼貌消息.

简要地

1. throw如果发生任何奇怪的事情,请不要犹豫在底层
2. 正如你的建议所说,不要处理你无法处理的异常(如果你遇到一个你无法处理的异常,请重新抛出它)
3. LOG !!!!!!!!!!!!!!!!!
4. 不要在公共网站上向最终用户透露异常详细信息,永远不要!默认情况下,ASP.NET会阻止它发生,但您仍然可以使用OnError来打印堆栈跟踪
5. 使用OnError或Application_Error作为单个中心点来处理所有意外异常
6. 定期检查日志以查找错误/致命消息以查找代码问题,然后考虑维护/调试/修复它