C# 处理特定实体框架例外-标准/指南？

使用实体框架从数据库中查询时，应捕获哪些异常，以及应如何处理这些异常？

通常我使用

catch（Exception）

，因为我没有针对每种可能的错误类型的具体操作或反馈，但我经常被提醒这是一个糟糕的想法，应该捕获和处理特定的异常！例如：

try
{
    using(MyEntities context = new MyEntities())
    {
        context.Companies.Attach(company);
        ActiveEmployees = company.Employees.Where(x => x.IsActive).ToList();
    }
}
catch(Exception ex)
{
    Feedback(FeedbackType.ApplicationError); // User feedback
    Logger.Log(ex);  // Log the exception
}

---

处理EF异常的标准/指南是什么？

这几条语句可能引发大量异常。 您可能没有与数据库的网络连接。 您附加的公司可能附加到另一个上下文。 员工可能不是虚拟的，或者一开始就没有加载，因此为空。 您必须检查每个方法的文档，并找出可能需要捕获的内容

但我的两分钱是你已经抓住了他们，你只能做你能做的事。 您将其记录下来，并询问用户他/她做了什么。（还可能给自己发封电子邮件？）

---

这样做一段时间后，您将有一个日志，显示实际发生的异常，您可以决定如何处理这些异常。但大多数情况下，用户只想知道站点已“关闭”，并将在n中进行备份。

许多异常不应被捕获，而应被阻止。我的意思是，在单元测试/集成测试中，诸如违反FK约束或其他数据库约束、附加已附加的实体、释放上下文时延迟加载、不受支持的LINQ语句等异常应该出现。这就是为什么我不会在代码的深处（看起来像某种存储库或服务方法）而在更高层（例如在UI或视图模型中）使用这样一个通用的try-catch。他们应该让你的测试崩溃

我可以想到一个例外，您可能希望捕获并处理接近数据访问代码的异常，那就是乐观并发性异常。这是因为在代码中无法完全防止并发冲突（计时总是留下间隙），并且当发生异常时，必须依靠数据库抛出异常。有关如何处理乐观并发的一些模式，请参见