在控制器级别捕获 SqlException？答案

【问题标题】：Catch SqlException at the controller level?在控制器级别捕获 SqlException？
【发布时间】：2016-03-30 11:34:27
【问题描述】：

在我的 WebApi 2 项目中，我遵循服务模式以及工作单元和通用存储库模式。

所有控制器都有try-catch，并且如果一个动作没有我有一个全局IAutofacExceptionFilter 将捕获未处理的异常。

服务层也有异常处理。但是，存储库没有异常处理，因此异常冒泡到他们遇到的第一个try-catch。

我还有一个自定义的DatabaseException 类，它可以捕获SaveChanges 上抛出的EF 数据库异常，这很好用。

但是，由于该项目目前正在大量开发中，数据库更改与代码更改同时发生，因此SQLException 或EntityCommandExecutionException 等异常非常常见。我想捕捉这些异常并抛出我自己的DatabaseException。

我应该在存储库级别、服务级别还是控制器级别捕获这些异常？

【问题讨论】：

尽可能靠近原点重新抛出。这样，您仍然可以根据需要进行区分。
我的建议是在控制器级别记录异常并使用来自控制器的通用消息抛出异常。

标签： c# entity-framework asp.net-web-api

【解决方案1】：

直接回答您的问题 - 我会在服务级别捕获异常，记录它们，然后重新抛出它们。

从数据库中检索数据是服务的一项功能，因此如果失败，就是服务失败了。
应用程序不“知道”数据库。它不会从数据库中获取数据。它从服务中获取数据。它不应依赖于服务中的实现细节，例如数据来自 SQL 还是其他地方。

现在异常被重新抛出，应用程序也可以处理它，甚至再次记录它——这次是在调用控制器操作的上下文中。但是，例如，如果用户试图保存一些数据并且失败了，那么在这种情况下失败的原因可能并不重要。所以捕获特定的异常类型可能没有多大帮助。（可能。）

仅当应用程序要采取一些不同的操作来处理或解决异常时，捕获特定类型的异常才真正有用，这并不常见。能够轻松访问您的日志并找到异常，任何异常都将比将系统异常转换为自定义异常更有价值。

【讨论】：

上下文中发生的错误将传播到您调用 _context. 的 BAL 或模型。如果这些函数包含在 try-catch 中，您将捕获异常。当您在 using 语句中初始化上下文时，它将捕获您的连接特定错误。
我的意思是更模糊的“上下文”——在控制器中处理请求时抛出的异常。

【解决方案2】：

我的 MVC 应用程序中通常没有 try_catchs（不包括一两个现有的 try catch）

我所有的控制器都继承自BaseController 我有一个属性可以捕获我的应用程序中的所有异常：

public class HandleExceptionsAttribute : HandleErrorAttribute
{
    public override void OnException(ExceptionContext filterContext)
    {
        filterContext.Exception.InsertIntoDB(Membership.CurrentUserId, filterContext.RouteData.Values["controller"].ToString(), filterContext.RouteData.Values["action"].ToString());
    }
}

[HandleExceptionsAttribute(View = "/Error/Index")]
public class BaseController : Controller
{
    // Code...
}

在HandleErrorAttribute 中，您甚至可以选择在发生错误时要显示的页面。

如果要过滤特定的异常：

if (filterContext.Exception is EntityCommandExecutionException)
                // code

注意

要查看异常发生在哪个动作和控制器中，我获取当前控制器和当前动作并将其插入数据库。

【讨论】：