编辑，首先阅读：这不是using语句吞噬了我的ApplicationException，而是我在实际代码中使用的DependencyResolver。我什至不认为首先要去那里看，但是可以肯定的是，如果我尝试直接实例化该类（与我在下面的简化示例代码中所做的相同方式），它将按预期工作。仅当我在using语句中使用DependencyResolver时，它的行为才与我在下面记录的方式一样。我根本就没有在我的问题中提及这一点，因为我忽略了它。我使用的是Unity容器，仅供参考。在处理过程中，我将对其进行更新，并且可能会删除它。
更新2：好的，事实证明，当服务位置引发异常时返回空资源是MVC内完全正常且预期的行为。当我第一次遇到这种行为并使自己感到困惑时，我只是完全不了解我正在使用依赖项注入这一事实。因此，如果有人发现自己处于类似情况，我将保留这个问题。创建使用DependencyResolver服务定位器解析的资源时，您不能引发异常！它将吞下异常并返回空资源！
同样，如果有人想知道我根据这些新信息所做的更改：我只是将我的数据库检查/异常抛出逻辑移到了存储库中而不是构造函数中的一些关键方法中。我也停止使用Unity并切换到Ninject，从服务定位器模式转到将我的容器包装在Singleton类中，但这与我遇到的导致该线程的问题无关，而更多的是风格上的选择。
结束编辑
所以可以说我有某种访问数据库的类，就像这样...
public class Foo : IDisposable {
private DbContext db = new FooDbContext();
public DoSomething(){
// do something with the FooDbContext...
}
// Dispose is implemented here as well...
}
当我使用该类时，我会像这样访问它...
using (Foo foo = new Foo()){
foo.DoSomething();
}
因此，我想完成的工作是，每当构造Foo类时，如果基础DbContext无法建立连接，就会引发ApplicationException。
所以我将以下构造函数添加到Foo类中...
public Foo() {
try
{
db.Database.Connection.Open();
}
catch
{
throw new ApplicationException("Database is not currently available. Try again later.");
}
}
但这是问题，回到这段代码...
using (Foo foo = new Foo()){
foo.DoSomething();
}
当在数据库不可用时执行了using语句时（我已经通过调试确认了这一点），在构造Foo时会抛出ApplicationException，但是，该ApplicationException被忽略，并且无论如何都会调用DoSomething方法。到那时，我得到的是NullReferenceException而不是所需的ApplicationException，因为foo为null。
我的ApplicationException怎么了？为什么它被忽略？我该怎么做才能确保ApplicationException冒泡？
我实际上并不想处理ApplicationException。在某些情况下，这是一个ASP.NET MVC应用程序。我希望不处理ApplicationException，并让我设置的自定义错误页面向用户显示ApplicationException中包含的消息。
最佳答案
我认为您的问题没有进入db和连接详细信息，这是由于using块引起的，using块吞没了构造函数中发生的异常。
http://www.digitallycreated.net/Blog/51/c%23-using-blocks-can-swallow-exceptions
https://msdn.microsoft.com/en-us/library/aa355056.aspx
关于c# - 如果在实例化DbContext资源的using语句内部数据库连接失败，如何自动引发ApplicationException？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38773305/