関数のコードのほとんどをに入れることに欠点はありますかtry statement
?を必要とする何かを行う場合try statement
、通常はtryステートメント内でその関数に対して多くの作業を行うことになります。これは、通常、変数をそこで宣言し、その範囲外で使用できないためです。これは一般的で受け入れられていますか?人々は通常、変数を初期化せずに宣言するので、?内ですべて(他の関数の呼び出しを含む)を実行しtry statement
ませんか?それとも、それが非常に長いかどうかは関係ありませんか?
4 に答える
メソッドは 1 つのことを行い、それを適切に行う必要があります。この場合、メソッドはビジネス ロジックとエラー処理の 2 つのことを行っています。
public Foo bar() {
try {
//business logic that may throw
//...
//end even more
} catch(BuzzException e) {
//Error handling
}
}
try
ブロックの内容をエラー処理なしで別のメソッドに抽出することがよくあります。
public Foo bar() {
try {
return unsafeBar();
} catch(BuzzException e) {
//Error handling
}
}
public Foo unsafeBar() throws BuzzException {
//business logic that may throw
//...
//end even more
}
それが非常に長いかどうかは重要ですが、あなたが考える理由ではありません. コードが読みにくく、テストしにくくなるため、これは重要です。いくつかの方法にリファクタリングすることをお勧めします。
public void doComplexThing() {
try {
SomeObject o1 = doSomethingLessComplex();
SomeOtherObject o2 = doSomethingElse(o1);
doFinalThing(o2);
}
catch (SomeException e) {
// handle the exception
}
}
ブロックが少し長くなる場合は、try
実際に例外をスローしている呼び出しを独自のメソッドに分離することをお勧めします。そうすれば、そのブロックでスローされるいくつかの種類の例外に個別に対処できます。
「謎の」バグをテストしたり見つけたりしようとしている場合try
、普通の古いもので多くの例外をカバーすると、後で頭痛の種になります。catch(Exception ex)
これは、多くのチェック例外が存在する適切なリソース/ストリーム処理のようなものは言うまでもありません。
上級プログラマーとして、例外をスローしているステートメントに対して完全に try catch を使用することと、コードをきれいにすることとの間の混乱を理解しています。
ここで私は の方に傾きtry catch over the statements that need it
ます。
まず、try catch の必要性を理解しましょう。ここで今すぐ処理したいので、例外をキャッチします。そうでない場合は、呼び出し元にスローします。後で処理を忘れないように投げます。決して、Oh!, let me finish this method and then I will worry about the exception handling later
. コーディング中にそれを行い、エラーを出力して null を返す必要があるか、または何かが台無しになったことをユーザーに知らせる必要があるかを考えます。すべての接続の問題をrecycle the connection
ちょっとしたメッセージにまとめますか? はいの場合は、独自のカスタム例外をスローします。しかし、必ずそれを処理してください。不適切な例外処理を無視して実行することは、プロジェクトの保守コストの増加と顧客の心痛の根本的な原因です。良い製品と下手な製品の違いです。
コードの簡潔さに関しては、catch ブロック内のコメントはすべての価値があることを発見しました。catch (Exception e)
はい、正確なステートメントをキャッチすることの重要性を理解せず、直接キャッチする上級者がいるでしょう。哀れだと思います。ただし、コーディングするときは、倫理に固執する必要があります。それを正しく行い、一度だけ行います。