1

そのせいで頭をよく打った。$etrap (エラー処理特殊変数) が考案された方法では、すべてのエラーを実際にトラップするように注意する必要があります。私はこれを行うことに部分的に成功しています。しかし、ユーザー モード (アプリケーション モード) で実行すると、アプリケーションを停止している内部キャッシュ ライブラリエラーが発生するため、まだ何かが欠けています。

私がしたことは：

ProcessX(var)

    set sc=$$ProcessXProtected(var)
    w !,"after routine call"
    quit sc

ProcessXProtected(var)

    new $etrap
    ;This stops Cache from processing the error before this context. Code
    ; will resume at the line [w !,"after routine call"] above
    set $etrap="set $ECODE = """" quit:$quit 0 quit"

    set sc=1 
    set sc=$$ProcessHelper(var)
    quit sc

ProcessHelper(var)

    new $etrap
    ; this code tells Cache to keep unwindind error handling context up
    ; to the previous error handling.
    set $etrap="quit:$quit 0 quit"

    do AnyStuff^Anyplace(var)

    quit 1

AnyStuffFoo(var)
    ; Call anything, which might in turn call many sub routines
    ; The important point is that we don't know how many contexts
    ; will be created from now on. So we must trap all errors, in any
    ; case.

    ;Call internal Cache library
    quit

このすべての後、プロンプトからプログラムを呼び出すと、プログラムが機能することがわかります! しかし、キャッシュ ターミナル スクリプト (アプリケーション モード) から呼び出すと、失敗してプログラムが中止されます (エラー トラップ メカニズムが期待どおりに機能しません)。

4

1 に答える 1

1

古いスタイルのエラートラップ（$ ZTRAP）がユーザーモードでのみ設定されている可能性はありますか？

これに関するドキュメントはかなり良いので、ここですべてを繰り返すことはしませんが、重要な点は、$ZTRAPが$ETRAPと同じように新しくないことです。ある意味で、その値は現在のスタックレベルと後続の呼び出しにのみ適用されるという点で、「暗黙的に新しい」ものです。設定されたレベルを超えて終了すると、以前の値に戻ります。

また、$ETRAPハンドラーと$ZTRAPハンドラーの間に優先順位が定義されているかどうかはわかりませんが、$ ZTRAPの優先順位が高い場合は、$ETRAPが上書きされます。

ライブラリ関数を呼び出す直前に、自分で$ZTRAPを設定してみることができます。$ ETRAPとは異なるものに設定して、どちらがトリガーされたかを確認できるようにします。

それでも役に立たないかもしれません。ライブラリ関数内で$ZTRAPが設定されている場合、新しい値が有効になるため、違いはありません。これは、$ZTRAPの値がスタックのさらに上のどこかから来た場合にのみ役立ちます。

どのライブラリ関数がこれを引き起こしたかについては言及していません。私の会社にはいくつかのライブラリ関数のソースコードがあるので、関数名を教えていただければ、何が見つかるかわかります。同じバージョンのキャッシュについて話していることを確認できるように、$ZVersionの値も教えてください。

于 2008-10-20T12:42:58.313 に答える