最終的なブロックにビジネスロジックを含めることをお勧めしますか?仕事が終わったら(成功したかどうかにかかわらず)メール通知を送信する必要があります。メールロジックをfinallyブロックに配置できますか?
4 に答える
私が考えることができる主な危険は、finally ブロックが、例外を黙って飲み込み、try ブロック自体から値を返す能力を持っていることです。
例えば、
try {
doSomethingFancy();
} finally {
sendEmail();
}
doSomethingFancy が例外をスローした場合、電子メールの送信を試みます。メールの送信が何らかの理由で失敗した場合、sendEmail は例外をスローする可能性があります。この例外は、最初にスローされた例外を「オーバーライド」するため、表示されることはありません。消えるだけです。
もっと多くの try / catch ブロックを使って防御的にコーディングすることもできますが、注意してください...
理想的には、Try ブロックにビジネス ロジックを配置し、Finally ブロックにはクリーンアップ タスクまたは try ブロックの成功または失敗に関係なく発生する必要があるすべての処理を含める必要があります。また、最終ブロックのコードが例外を引き起こさないことを確認する必要があります。そうしないと、スティーブンが述べたように、元の例外があったとしても失われます。
指定された電子メール ID にエラー状態を送信する場合は、catch ブロックでそれを行うことができます。finally ブロックは、通常、ほとんどのリソースのグレースフル リリースに使用されます。メールを送信したり、finally ブロック内でビジネス ルールを実行したりすることはお勧めしません。
私の考えでは、
try {
doSomethingFancy();
catch(Exception ex) {
logError(ex);
}
sendMail();
これには最適なパターンです。finally ブロックは、try ブロック内のコードが残した可能性のある混乱をきれいにするためにのみ使用する必要があります。