0

这是此处DevForce 论坛的另一个主题的延续。问题是如果更改是由查询或导入触发的，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）。

4

1 回答 1

1

版本 7.2.4 包含一个标志 EntityManagerOptions.ThrowAllLoadExceptions 来控制此行为。 发行说明。

于 2014-08-05T23:44:52.937 回答