这是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)是#34;在查询过程中失败通常不是 开发商的实际意图&#34;因为它更有可能 由于编写错误的事件处理程序而发生
也许我们不常见:-),但在我们的应用程序中,事件处理程序如下所示:
EntityManager.EntityChanged += (sender, e) =>
{
if (e.Action == EntityAction.AddOnAttach ||
e.Action == EntityAction.AddOnImport ||
e.Action == EntityAction.AddOnQuery)
{
((MyBaseClass) e.Entity).Initialize();
}
};
这里抛出的任何异常都不会是因为编写错误的事件处理程序。在这里抛出的任何异常都是因为实体在执行其一次性初始化逻辑时非常困惑。而且该逻辑中的错误非常对我们很重要。
我可以理解,普遍改变它可能是危险的,并导致其他应用程序开始破坏。但是,如果我们可以通过某种方式关闭此行为或以其他方式告诉实体管理器不要吞下异常,那将非常非常有用。
我们之前的解决方法开始失败,因为我们希望在Web服务中使用所有业务逻辑,我们不能仅仅依靠错误记录来处理这类事情。我们无法取得成功&#39;因为DevForce吞噬了一个可能致命的错误而对调用者做出响应。
我们正在使用DevForce的最新版本(截至撰写时:2012 - 7.2.3)。