如何以及在何处处理三层Web应用程序中的异常?特别是SQL数据库异常

没有简单的答案或模式可以确保成功。就像你一样 验证 策略,您的确切异常处理策略是特定于您的具体情况的,并且通常是时间和全面性之间的权衡。不过,我们可以给出一些很好的建议:

• 不要隐藏堆栈跟踪;不要使用“rethrow”,除非出于安全目的您想隐藏发生的事情。
• 不要觉得到处都需要错误处理。默认情况下,在较低的层中,让实际错误渗透到最高层并不坏。在UI/控制器中,您必须真正决定如何对发生错误的事情做出反应。
• 在每一点上,像你自己一样,如果出了什么问题,你到底想要发生什么。通常,您不会想到比让它进入顶层甚至进入客户机更好的事情。(尽管在制作过程中会出现冗长的报告。)如果是这种情况,就让它过去吧。
• 确保处理非托管资源(实现IDisposable的任何资源)。您的数据访问就是一个很好的例子。要么( 一 调用 处理() 用于连接、命令、数据阅读器等。 终于 块,或( 乙 )使用 Using Syntax/Pattern 这确保了适当的处理。
• 寻找可能出现错误的地方,在那里您可以查找某些错误,作出反应(通过重试、等待第二次重试、以不同的方式尝试该操作等),然后希望成功。您的许多异常处理都是为了取得成功,而不仅仅是为了很好地报告失败。
• 在数据层中,您必须考虑在多步骤过程中出现问题时应该做什么。你可以让实际的错误渗出来,但是这个层 必须 处理出错后的整理工作。有时您会希望使用事务。
• 在异步情况下(a)因为多个线程,或者b)因为业务逻辑是在“任务机”上单独处理的,等等,稍后再处理的,所以您特别需要有一个记录错误的计划。
• 我宁愿在你的应用程序中看到25%的“错误处理代码”,而不是100%。100%意味着你可能希望它看起来和感觉你有错误处理。25%意味着你花时间处理那些真正需要处理的异常。

只是一个可能引导您思考的侧重点:如果您有可能导致并发问题(死锁)的任何类型的卷,您将希望应用程序检测到特定的SQL错误,然后重试该操作(例如事务)。这就要求在数据层或业务层进行一些异常处理。

-克里普

我相信在最后一个负责任的时刻处理异常是最好的做法。这通常意味着在UI级别(即MVC应用程序中的控制器或传统ASP.NET应用程序中的代码隐藏)。在这个高层次上,您的代码“知道”用户在问什么,如果某件事情不起作用,需要做什么。

处理调用堆栈中较低级别的异常通常会导致调用代码无法正确处理异常情况。

在您的数据层中,您将使用标准模式(例如 using statement 对于IDisposables(如sqlconnection),记录异常 知道 可能会发生(不要在内存不足或其他罕见情况下执行此操作),然后让它们在执行此操作时向上流动到调用堆栈。最多您可能希望捕获这些异常并将它们包装在一个异常类型中,在许多异常可能必须由调用方处理的情况下。

如果你需要在排除异常之前“清理”东西,你可以使用 finally block 清理。你不必 catch 为了使用 最后 块。

我不知道有什么小网站的例子是为了强调正确的异常处理,对不起。

这不是您问题的具体答案,但如果您对最佳实践感兴趣,我将介绍Microsoft模式和实践:

Application Architecture Guide

Web Applications Guides