問題タブ [rethrow]

try/catch ブロックをどこにでも置かずに例外を処理するためのベスト プラクティスは何ですか?

例外の受信と処理に専念するクラスを作成するというアイデアがありましたが、それが良い設計アイデアかどうか疑問に思っています。そのようなクラスは例外を受け取り、そのタイプまたはエラー コードに応じてそれをどう処理するかを決定し、特定の情報についてスタック トレースを解析することさえできます。

背後にある基本的な考え方と実装は次のとおりです。

これは興味深い試みだと思いました。理論的には、main() メソッド呼び出しの周りに 1 つまたはごく少数の try / catch ブロックしか必要なく、例外クラスが再スロー、処理、ロギングなどすべてを処理できるからです。

考え？

上記の例では、太字の行で、「キャッチ ブロックで新しい例外がスローされたため、元のスタック トレースが失われる可能性があります」という PMD エラーが発生しています。この質問は何度も聞かれていることも知っていますが、同じことについてオンラインで参照できる情報もたくさんあります。私は可能なすべての方法を試しました。しかし、それでもこの PMD エラーを取り除くことはできません。このコード スライスの問題点を教えてください。前もって感謝します！

次の C++ コードを検討してください。

ブロック内にないため、答えはノーだtryと思います。別の質問で、Javaの答えはノーですが、C++もノーであることを確認したいと思います。はい、テスト プログラムを実行できますが、コンパイラにバグがあるリモート ケースでの動作の言語定義を知りたいです。

より正確な再スローにより、実際にスローされた例外をスローするコードを記述できます。

Java 7 より前は、次のように記述する必要がありました。

私の質問Exception: " " を " "に置き換えるために不正確なスローを検出できるツールはありますFirstException, SecondExceptionか?

これまでのところ、Eclipse でコンパイラの警告がないことを確認しました。FindBugs や CodePro にはルールはありません。

Java では、一般的な例外がキャッチされて再スローされた場合、外部メソッドは引き続き特定の例外をキャッチできますか?

言い換えれば、私はこれを行うことができます:

2 つの質問 1) オブジェクト/変数が catch にスローされるとどうなりますか? たとえば、

この状況で、ここで何が起こりますか？新しい変数が作成されて渡されました???

参照なしでポインターまたは変数を使用するとどうなりますか

catch(int *i) // または catch (int i) のように

また、スコープ内で宣言または開始されたすべての変数/リソースは解放/クローズされていますか?

2) 再スローの場合も、参照を使用して再スローする場合、2 番目のキャッチは新しい変数を取得します。参照なしで (つまり) 値で再スローすると、中間スローで行われた変更は影響を受けません。 ....

OUTPUT: catch(int &i) // 2 を出力します catch(int i) // 1 を出力します

私の判断では、

私が思うのは、それが参照である限り、中間ステップで「値渡し」すると値が影響を受けるということです。元のオブジェクトを 2 番目のキャッチにスローします。

(つまり) 変数の制御フローは実際には中間キャッチをスローしません.....

私は例外を再スローすることで多くの実験を行い、次の結論に達しました。

1）（内部例外）のような例外についての詳細を提供したい場合は、再スローすることをお勧めします

2）プログラムを完全に終了するために再スローする場合があります。

3）再スローしたいがプログラムを終了したくない場合は、ループで再スローされた例外を処理する必要があります...

私はこれをしながら次のことを試みました：

次にmain（）で：

ループで再スローされた例外を処理しない場合、プログラムは終了します...つまり、これは、私が提示した上記の3つの結論が、再スローされた例外に関して正しいことを意味しますか？

UIレイヤーとビジネスレイヤーに分割されたc＃のプロジェクトがあります。基本的に口座を選択して入金番号を入力できるフォームがあります。[OK]ボタンをクリックすると、DepositTransaction.csがトランザクションを処理します。

DepositFormのサンプルコードは次のとおりです。

そして今、DepositTransactionのサンプルコード

ただし、上記を試しても、エラーはフォームに渡されません。例外が処理されなかったと言ってプログラムをクラッシュさせるだけです。

エラーを渡す方法は単に使用することthrow:であり、そのエラーはこのクラス（私の場合はフォーム）を呼び出したクラスに渡され、フォームで処理されるというスタックオーバーフローに関する別の質問を見ました。

私は何が間違っているのですか？ありがとうございました

onCreate（）で、UncaughtExceptionハンドラーを次のように設定しました。

正常に動作しますが、ユーザーに強制終了ダイアログを表示するというシステムのデフォルトの動作に戻したいと思います。

KillProcess()呼び出しをコンパイラに置き換えようとするとthrow throwable、コンパイラは、try/catchで呼び出す必要があると文句を言います。

try / catchで囲む場合：

throw throwableコンパイラは、try/catchで囲む必要があると文句を言います。

そのスローアブルを再スローするにはどうすればよいですか？その情報を除いてLog.e()、システムは以前とまったく同じように動作します。デフォルトのUncaughtExceptionハンドラーを設定したことはありません。

私はこれに数回遭遇しましたが、.NET 操作がより具体的なものではなく System.Exception をスローする必要があるというのは、非常に間違っているように思えます。この特定のインスタンスを InvalidCastException として再スローしてはならない理由はありますか? このケースを InvalidCastException ハンドラとひとくくりにする方が適切ではないでしょうか?

コンテキストについては、メソッドは次のとおりです。

Dim prs[...]Return prs上記の System.Exception キャッチでラップすることを検討しています。

原因は、文字列が単に "" の場合の System.Exception " is not a valid value" 例外です。

どのような例外が「あるべき」ですか? それとも、System.Exception は本当にこの場合の良い例外なのでしょうか?

編集: さらに考えてみると、System.Exception は単にメソッドがそのように呼び出された結果なのでしょうか? Int32.Parseメソッド (文字列)は、その関数によってスローされた例外であることを示しFormatExceptionています。これは、このケースを考慮するのに最適な例外でしょうか?