【发布时间】：2014-07-22 18:35:25
【问题描述】：
这是 DevForce 论坛here 的另一个主题的延续。问题是如果更改是由查询或导入触发的，DevForce 将默默吞下任何由 EntityManager.EntityChanged 事件引发的异常。相关代码如下所示：
internal virtual void OnEntityChanged(EntityChangedEventArgs args)
{
EventHandler<EntityChangedEventArgs> entityChanged = this.EntityChanged;
if (entityChanged == null) return;
try
{
entityChanged(this, args);
}
catch
{
if (args.Action != EntityAction.AddOnQuery && args.Action != EntityAction.AddOnImport)
{
throw;
}
}
}
正如论坛帖子中提到的，此方法的行为发生了一些超时。现在吞下的东西比我第一次抱怨这个时要少。但是对于我们的应用程序，我们真的需要知道什么时候出了问题。仅仅因为我做查询或导入操作时发生了错误并不意味着我不关心异常。
在上一篇论坛帖子中，这种行为的基本原理是：
吞下 AddOnQuery 期间抛出的异常的参数（和 AddOnImport）是“在查询中间失败通常不会 开发人员的实际意图”，因为它更有可能 由于写得不好的事件处理程序而发生
也许我们不常见 :-)，但在我们的应用程序中，事件处理程序如下所示：
EntityManager.EntityChanged += (sender, e) =>
{
if (e.Action == EntityAction.AddOnAttach ||
e.Action == EntityAction.AddOnImport ||
e.Action == EntityAction.AddOnQuery)
{
((MyBaseClass) e.Entity).Initialize();
}
};
这里抛出的任何异常都不会是因为事件处理程序写得不好。此处抛出的任何异常都是因为实体在执行一次性初始化逻辑时变得非常混乱。该逻辑中的错误对我们来说非常很重要。
我可以理解，普遍更改此设置可能很危险，并导致其他应用程序开始崩溃。但是，如果我们可以通过某种方式关闭此行为或通过其他方式告诉实体管理器不要吞下异常，那将非常非常有帮助。
我们以前的解决方法开始失败，因为我们希望在 Web 服务中使用我们所有的业务逻辑，我们不能仅仅依靠错误日志来处理这种事情。我们不能仅仅因为 DevForce 吞下了一个潜在的致命错误就向调用者返回“成功”响应。
我们使用的是最新版本的 DevForce（撰写本文时：2012 - 7.2.3）。
【问题讨论】：
-
我们可以重温一下。如果事实证明由于其他一些 DevForce 不当行为而导致异常被吞没，那么我认为我们不会改变这个逻辑；但除此之外，这可能是我们可以在下一个版本中解决的问题。
-
据我所知（我想这与一粒盐），
EntityChanged事件根本不被 DevForce 使用......所以我不认为我们会不得不担心这种变化会影响标准的 DevForce 行为。 -
@KimJohnson 你什么时候知道这是否会进入下一个版本？甚至你打算如何修复它？我想提前计划一下——如果事实证明这不会在 DevForce 中修复（或者以一种最终无法解决我们所有问题的方式修复），我需要回到绘图板.. .
-
计划在 7.2.4 版本中发布，但尚未完成。我们可能会在下周初为您提供 RC 版本。
-
好吧，这种行为有很长的拜占庭历史，可以追溯到 5 年前，而最简单的方法，不费心去捕捉和吃掉这些异常，可能是不可行的。使 EntityManager 上的 OnEntityChanging/Changed 方法对您有用吗？如果您仍想从覆盖的方法中调用处理程序，我们还可以添加辅助方法来执行此操作。