2

私はこの問題に何度か遭遇しましたが、解決できませんでしたが、今は完全に解決する必要があります。

実行時エラーをスローしているプロシージャがあります。関数の上部に定義されたエラーハンドラーと、下部に次のようなハンドラーがあるため、これは問題ではありません。

retryConcat:
On Local Error GoTo concatErr
    'Some Code here
    Exit Sub
concatErr:
    If MsgBox("Could not append the receipt for this transaction to the Receipt viewer logs.", vbExclamation + vbRetryCancel, "Warning - Missing Receipt") = vbRetry Then
        err.Clear
        GoTo retryConcat
    End If

エラー ハンドラにはメッセージ ボックスが含まれており、ユーザーは必要に応じて再試行できます。ここが私を混乱させる部分です。初めてエラーがスローされると、メッセージ ボックスが表示され、ユーザーは期待どおりに再試行できます。その後、プログラムは適切な行にジャンプして再試行します。ただし、エラーがスローされた 2 回目は、エラー ハンドラにジャンプせず、プロシージャからジャンプして、代わりに親のエラー ハンドラがキャッチします。

したがって、私の質問は、後続のスローで親エラーハンドラーにジャンプするのはなぜですか。これは、コード全体の多くの場所で発生します。エラーを手動でチェックできる多くの場合、コードを while ループに入れて解決することができますが、実行時エラーが発生すると、このかなり厄介な方法で動作するエラー トラップを使用せざるを得なくなります。

ヘルプやアドバイスをいただければ幸いです。

4

1 に答える 1

4

使用する必要はありませんResume retryConcat。

エラーが発生すると、エラーハンドル to にジャンプしますconcatErr:。次に、メッセージ ボックスを表示し、ユーザーが再試行することを選択した場合、コードは にジャンプしretryConcatます。あなたが使用Gotoしたように、それはエラーハンドラーを終了しません。そのため、次にエラーが発生したとき、それはすでにエラーハンドラーにあり、チェーンを呼び出し元のプロシージャーにエラーを発生させるしかありません。

を使用Resume concatRetryすると、エラー ハンドラを終了し、必要なポイントで再開できます。つまり、次にエラーが発生したときに、再び処理できます。

エラーハンドラーがコードのセクションではなく状態であると想像すると、おそらく理解しやすくなります。

于 2012-09-26T14:33:45.390 に答える