例外理由/メッセージ。私はここに車輪を再発明していますか？

Question

キャッチされた例外についてより多くの情報を取得するためのメカニズムが必要です。 （特にトランザクションを中止するために私は自分自身を投げる例外がある）私は見てきたが、私が見つけることができる唯一のものは "情報ログを使う"であった。これは私にとっては良い考えのようには見えません。 1つは、最後のメッセージにアクセスして見つけることが面倒です。サイズには限界があり、ある時点で新しいメッセージは表示されません。

私の考えは次のとおりです。クラスNuExceptionを作成し、 すべてのメソッドを通じてそのインスタンスを渡します。 作業メソッドがあるクラスにインスタンスを格納します。私は例外をスローする必要があるときに私はGlobal::error()に似たメソッドを呼び出しますが、これは識別子とメッセージを取ります。

キャッチブロックに達すると、 オブジェクトからアクセスできます。 CLRExceptionsの動作と同様に、ワークメソッドを含むクラスです。

class NuException 
{ 
    "public" str identifier; 
    "public" str message; 

    public Exception error(str _id, str _msg) 
    { 
    //set fields 
    return Exception::Error; 
    } 
} 

class Worker 
{ 
    "public" NuException exception; 

    void foo() 
    { 
    throw this.exception.error("Foo", "Record Foo already exists"); 
    } 

    void bar() 
    { 
    this.foo(); 
    } 
} 

void Job() 
{ 
    Worker w = new Worker(); 
    try 
    { 
    w.bar(ex); 
    } 
    catch (Exception::Error) 
    { 
    info(w.exception().message()); 
    } 
} 

これは機能しますが、より良い方法はありませんか？確かに誰かがこのAXの欠点を回避するための解決策を考え出す必要がありますか？

Answer 1

短い回答：はい。

NuExceptionオブジェクトをリスナー（job）からスローダ（foo）まで20レベル下に移動する必要があるため、「ブリリアント」スキームが「機能する」とはかなり退屈です。あなたのbar方法と他の中間の男性はあなたの例外制度について興味も知識もありませんが、とにかくそれを渡す必要があります。
これは、アップデート後のケースではなくなりました。

いくつかの方法があります。

1. Event brokerまたはAX 2012およびそれ以降の使用delegatesのようobserver patternを使用してください。

2. システムに固執し、InfoActionクラスを使用して、後で使用するために情報をペギーすることができます。これは、スタックトレースまたはその他の興味深い情報を表示するために使用できます。

3. ロギング専用テーブルを使用します。

第3の方法は、エラーがログの挿入を取り消すため、実際的ではないように見えるかもしれません。これはデフォルトの動作ですが、回避することができます。

MyLogTable log; 
Connection con = new UserConnection(); 
con.ttsBegin(); 
log.setConnection(con); 
... // Set your fields 
log.insert(); 
con.ttsCommit(); 

あなたが行く方法は、あなたが言及していない状況によって異なります。