2

多くのCachéAPIメソッドは、これがエラーであるかどうかを示す％Statusオブジェクトを返します。問題は、それが未知のエラーである場合、（ネットワーク障害のように）処理方法がわからない場合、本当にやりたいことはエラーを「スロー」することです。これにより、コードが実行を停止し、エラーがより高いレベルでキャッチされます。レベルのエラーハンドラ（および/または組み込みの％ETNエラーログ）。

私はztrap次のように使用できます：

s status = someObject.someMethod()
ztrap:$$$ISERR(status)

しかし、それはあまり詳細を報告していません（たとえば、スタックの一番上まで例外をスローできる.NETとは異なり）、これを行うためのより良い方法があるかどうか疑問に思っています。

4

2 に答える 2

2

%Exception.StatusException のクラス リファレンスを参照してください。次のように、ステータスから例外を作成し、その時点でアクティブなエラー トラップにスローすることができます (したがって、制御の流れは ZTRAP の例と同じになります)。

set sc = someobj.MethodReturningStatus()
if $$$ISERR(sc) {
   set exception = ##class(%Exception.StatusException).CreateFromStatus(sc)
   throw exception
}

ただし、この例外をキャッチするエラー トラップ コード内の例外情報を回復するには、try/catch でエラー トラップが確立されている必要があります。古いエラー ハンドラーである $ztrap と $etrap は、例外オブジェクトを提供せず、$ZERROR 値として <NOCATCH> エラーがあることだけが表示されます。その場合でも、制御の流れは思い通りに機能しますが、try/catch がなければ、ZTRAP を使用した場合よりもうまくいきません。

于 2011-10-27T21:11:22.300 に答える
1

これらは 2 つの異なるエラー メカニズムであり、このように組み合わせることはできません。ztrap と %ETN は、キャッシュ レベル エラー (のような山かっこエラー<UNDEFINED>) 用です。%Status オブジェクトは、アプリケーション レベルのエラー (キャッシュ クラス ライブラリを使用して発生したエラーを含む) 用であり、それらの処理方法を自分で選択できます。キャッシュ エラーが発生していないため、キャッシュ エラー メカニズムを介して不正な %Status を処理しても意味がありません。

一般的に、ほとんどの人が行うことは、次のようなことです。

d:$$$ISERR(ステータス) $$$SomeMacroRelevantToMyAppThatWillHandleThisStatus(ステータス)

アプリケーションに付随する %msg 値を持つ %Status コードの独自のホスト全体を使用して、独自のドメインを作成することができます。あなたのアプリは FTP サーバーに接続しようとして間違ったパスワードを使用した可能性がありますが、それはエラーをスローせず<DISCONNECT>、スタックを調査する理由はありません。処理が必要なアプリケーション レベルのエラーであり、おそらくユーザーに確認する必要があります。新しいパスワードを入力します。

これら 2 つのエラー メカニズムが並行して存在するのは奇妙に思えるかもしれませんが、これらは 2 つの異なるタイプのエラーを説明しています。そのうちの 1 つは「プラットフォーム」レベルのエラーであり、もう 1 つは「アプリケーション レベルのエラー」であると考えてください。

編集:私が忘れていたことの1つは、 DecomposeStatus^%apiOBJ(status) または ##class(%Status).LogicalToOdbc(status) を試して、ステータスオブジェクトを人間が読める文字列に変換してください。また、コマンド ライン デバッグを行っている場合、または読み取り可能なフォームをプリンシパル デバイスに出力したい場合は、$system.OBJ.DisplayError(status) を使用できます。

于 2011-10-07T02:38:55.677 に答える