問題タブ [try-catch-finally]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
6 に答える
66315 参照

java - Java の finally ブロックから戻る

最近、Java の finally ブロックに return ステートメントを含めることができることに驚きました。

「 finally 句で返さない」で説明されているように、多くの人が悪いことだと考えているようです。もう少し掘り下げてみると、「Java's return does not always」も見つかりました。これは、finally ブロックでの他のタイプのフロー制御の非常に恐ろしい例を示しています。

それで、私の質問は、finally ブロックの return ステートメント (または他のフロー制御) がより優れた/より読みやすいコードを生成する例を誰か教えてもらえますか?

0 投票する
16 に答える
5490 参照

.net - finally ブロックのポイントは何ですか?

構文はさておき、違いは何ですか

編集:.NET 2.0で?


それで

行動的に同等ですか?

0 投票する
51 に答える
562778 参照

java - 最終ブロックは常にJavaで実行されますか?

このコードを考えると、何が何であれ、ブロックが常に実行されることを絶対に確信できますか?finallysomething()

0 投票する
20 に答える
90838 参照

c# - なぜ{...}を最後に{...}試してみるのが良いのですか。{...}キャッチ{}を試してみてください。

引数なしでcatchを使用するのは悪い形式であると人々が言うのを見たことがあります。特に、そのcatchが何もしない場合はそうです。

ただし、これは適切な形式と見なされます。

私が知る限り、finallyブロックにクリーンアップコードを配置することと、try..catchブロックの後にクリーンアップコードを配置することの唯一の違いは、tryブロックにreturnステートメントがあるかどうかです(この場合、finallyのクリーンアップコードは実行しますが、try..catchの後のコードは実行しません)。

そうでなければ、最終的に何がそんなに特別なのですか?

0 投票する
6 に答える
75695 参照

c# - try catchfinallyブロック内から戻るのは悪い習慣ですか?

だから私は今朝、次のようなコードに出くわしました:

これで、このコードは正常にコンパイルされ、正常に機能しますが、特に最終的に関連付けられている場合は、tryブロック内から戻るのが適切ではないと感じます。

私の主な問題は、最終的にそれ自体の例外をスローした場合にどうなるかということです。返された変数がありますが、対処するための例外もあります...それで、他の人がtryブロック内から戻ることについてどう思うか知りたいですか?

0 投票する
12 に答える
20017 参照

c# - catchブロックのないfinallyブロックはJavaアンチパターンですか?

次のようなコードのトラブルシューティングで、かなり苦痛なトラブルシューティングの経験がありました。

doSomeStuff() が例外をスローし、それが doSomeOtherStuff() も例外をスローする原因となったため、この問題のトラブルシューティングは困難でした。2 番目の例外 (finally ブロックによってスローされた) がコードにスローされましたが、最初の例外 (doSomeStuff() からスローされた) のハンドルがありませんでした。これが問題の本当の根本原因でした。

コードが代わりにこれを言っていたら、問題はすぐに明らかになったでしょう:

だから、私の質問はこれです:

catch ブロックなしで使用される finally ブロックは、よく知られている Java アンチパターンですか? (これは確かに、明らかによく知られているアンチパターン「例外をゴブリングしないでください!」の、あまり目立たないサブクラスのようです)。

0 投票する
1 に答える
652 参照

c# - スレッドシングルスレッドアパートメントスレッドからリソース/メモリを要求する

私は次のシングルスレッドのアパートを使用しています。スレッドオブジェクトからメモリ/その他のリソースを再利用できません。Actullayスレッドをtrycatchとfianllyblockでラップしたいと思います。試してキャッチが行われます。しかし、私は最終的にブロックすることについてはわかりません。finallyブロックで呼び出す必要のあるコード、プロパティ、または関数は何ですか。

0 投票する
11 に答える
1279 参照

c# - 読みにくい try..catch..finally ブロックのフォーマット?

try..catch.finallyブロックをどのようにフォーマットしていますか? 特に、少量のコードだけをラップすると、すべてが吹き飛ばされ、コードがかなり読みにくく、見苦しくなります。

そのような:

これらの 7 行のコードは、16 行の混乱に変わりました。

より良いtry..catch..finallyフォーマットに関する提案はありますか?

0 投票する
6 に答える
21563 参照

exception - Try、Catch、Finally内で例外をスローするVSエラーを返す

私はすでに答えを知っていると確信していますが、Try、Catch、Finally ブロック内でエラーを処理することについての意見がどうなっているのか、まだ興味があります。

ところで-私はユーザー入力について話しているのではありません-しかし、それは明確で短いので、例として使用します

このコードを考えてみましょう...

関数が失敗した場合、例外は無関係であるため、エラー メッセージを返したいとします。関数は成功せず、ユーザーは追加の詳細を必要としません。

私は常に、エラーを処理できる場合は例外を回避するという信念を持っていました-それはもはや例外的ではないためです.あなた自身...

これは最良の例ではありませんが、コードを繰り返すことを強調するために簡潔にするつもりでした。

例外はパフォーマンスの低下を招くことが知られていますが、このような状況についてはどう考えていますか?