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();
    }
};

ここでスローされる例外は、イベント ハンドラーの書き方が悪いためではありません。ここで例外がスローされるのは、1 回限りの初期化ロジックを実行中にエンティティが非常に混乱したためです。そして、その論理の誤りは私たちにとって非常に重要です。

これを普遍的に変更することは危険であり、他のアプリケーションが壊れ始める可能性があることは理解できます。しかし、この動作をオフにする方法や、Entity Manager に例外を飲み込まないように指示する方法があれば、非常に役に立ちます。

以前の回避策は失敗し始めています。Web サービスですべてのビジネス ロジックを使用しようとしているためです。この種の処理をエラー ログだけに頼ることはできません。DevForce が潜在的に致命的なエラーを飲み込んだという理由だけで、呼び出し元に「成功」​​の応答を返すことはできません。

DevForce の最新バージョンを使用しています (この記事の執筆時点: 2012 - 7.2.3)。

4

1 に答える 1

1

バージョン 7.2.4 には、この動作を制御するフラグ EntityManagerOptions.ThrowAllLoadExceptions が含まれています。 リリースノート。

于 2014-08-05T23:44:52.937 に答える