我有一个全局中间件来处理应用程序抛出的异常。除了数据库级别的操作失败之外,它按预期工作。当我遇到实体框架报告的问题时(由于 Context 定义或其他数据库相关操作中的配置有缺陷),异常不会报告,即使我在调试期间单步执行执行也是如此。
相反,这种(对我来说令人困惑和沮丧的)现象出现了。执行下面的(正确且现在有效)代码,只需离开服务,将黄色箭头移动到控制器的返回语句,然后存在向 Swagger 报告 200 OK 的请求(尽管没有数据)。
Thing[] output = Context.Things
.Include(a => a.SubThings)
.Where(a => a.Id == id)
.ToArray();
请注意,上面的示例确实有效并且没有问题除非我在其他地方犯了错误。例如,我将域模型的
List<SubThing> SubThings {get;set;}=[]
更改为 IEnumerable<SubThing> SubThings {get;set;}=[]
(这消除了将元素添加到集合中的能力)和 SubThing[] SubThings {get;set;}
(不允许用于导航集合)。 (注意。我知道为什么会出现这些错误,并且我不询问如何解决它们。这只是问题的背景信息。)
首先经过(过于广泛的)调试,我发现了这个问题。然后,通过 try-catch 包围失败的操作,让我遇到了错误。
try
{
Thing[] output = Context.Things
.Include(a => a.SubThings)
.Where(a => a.Id == id)
.ToArray();
}
catch(Exception exception) { ... }
这让我很困惑,我觉得我错过了一些东西。我的印象是中间件(注册为最外层范围)将拦截所有内容。失败的操作是在请求内执行的,因此传递了一堆其他“内部”中间件。从我的角度来看,EF 期望似乎从应用程序中获得了快车道。
通过谷歌搜索该问题,可以找到有关如何设置中间件以及如何纠正错误配置的中间件的信息。为了以防万一,我已经检查了所有这些信息,但除了确认我遵循了标准程序之外,我没有注意到任何信息。
Swagger 报告200 OK而不是500内部服务器错误也很奇怪
catch(Exception exception) { throw; }
但处理得很好
catch(Exception exception) { throw new DedicatedCustomException(); }
但是,我的问题是,我是否真的必须使用显式的 try-catch 策略,而不是对所有不好的事情进行隐式错误管理。如果我必须在每次调用数据库时显式地重复 try-catch,它会对代码库大小产生影响。
你是对的,处处有 try-catch 并不理想,应该避免,除非这样做在你的设计中有意义(例如,5 个步骤的过程,每个 5 个步骤都有一个 try-catch)。
您可以按照此处所述配置全局异常处理。