問題タブ [try-catch]

私は自分のアプリケーションの1つにグローバルエラー処理「モジュール」を書いています。

私が望んでいる機能の1つは、関数をブロックで簡単にラップできるようにすることですtry{} catch{}。これにより、その関数へのすべての呼び出しに、グローバルロギングメソッドを呼び出すエラー処理コードが自動的に含まれるようになります。（try / catchブロックでどこでもコードを汚染しないようにするため）。

.callただし、これは、JavaScript、 and.applyメソッド、およびthisキーワードの低レベルの機能についての私の理解をわずかに超えています。

Function.wrap私はプロトタイプの方法に基づいてこのコードを書きました：

これは次のように使用されます：

そのコードは完全に機能します。6を出力してから、グローバルエラーハンドラを呼び出します。

私の質問は、ラップしている関数がオブジェクト内にあり、「this」演算子を使用している場合、これは何かを壊しますか？.applyと呼んでいるので少し心配ですが、そこに何かを渡すと、何かが壊れるのではないかと心配しています。

より良いコーディングの実践/より効率的なコードの作成/よりきれいに見える/何でもあなたの考えをいくつか教えてください：潜在的な問題を予測してキャッチするためにifステートメントを使用する能力を向上させますか？それとも、単にtry / catchを一般的にうまく利用していますか？

これがJava用だとしましょう（重要な場合）。

編集： 私は現在、明らかに時代遅れで制約のある現在のコーディング慣行から自分自身を移行していますが、いくつかの点（このような）でそうする必要性に少し引き裂かれています。私は単にこれについていくつかの見方を求めています。議論ではありません。

この関数には "{" と "}" の本体がないことに注意してください。ただの try/catch ブロック:

これは意図的に C++ の一部ですか、それとも g++ 拡張機能ですか?

これには、{} の 1 レベルをバイパスする以外に何か目的はありますか?

http://stupefydeveloper.blogspot.com/2008/10/c-function-try-catch-block.htmlに出くわすまで、これについて聞いたことはありませんでした。

未処理の JavaScript 例外をログに記録しようとしています。例外がキャッチされなかったときに発生するイベントはありますか? ブラウザーで JavaScript エラーが発生する前に例外をキャッチしようとしていますが、アプリケーション全体を try/catch 内で実行したくありません。どんな助けでも大歓迎です。ありがとう！

更新: tvanfosson は可能性として onerror を指摘しました。これは仕様の一部ではなく、IE または Gecko ベースのブラウザーでのみ使用できます。

詳細については - http://books.google.com/books?id=tKszhx-XkzYC&pg=PA386&lpg=PA386&dq=safari+onerror+javascript&source=web&ots=gQaGbpUnjG&sig=iBCtOQs0aH_EAzSbWlGa9v5flyo#PPA387,M1

OnError サポート表 - http://www.quirksmode.org/dom/events/error.html

Mozilla のドキュメント - https://developer.mozilla.org/en/DOM/window.onerror

WebKit バグ レポート - https://bugs.webkit.org/show_bug.cgi?id=8519

ある友人のコードをレビューしていて、彼は try-finally ブロック内で return ステートメントを使用していたと言います。try ブロックの残りの部分は起動しませんが、Finally セクションのコードは起動しますか?

例：

これは、標準 C++ で Final のような動作を実装する良い方法ですか? (特別なポインタなし)

1. オブジェクトによって例外がスローされない -> NoException -> オブジェクトがクリーンアップされる
2. オブジェクトによってスローされた例外 -> 処理済み -> NoException -> オブジェクトのクリーンアップ
3. オブジェクトによってスローされた例外 -> スローされた -> 例外 -> オブジェクトがクリーンアップされた -> スローされた

Java言語仕様によると：

try ブロックに throw ステートメントが含まれている外側の try ステートメントがある場合、それらの try ステートメントの finally 句は、スローされた値がキャッチされるまで、制御が外側に転送されるときに実行されます。finally 句が突然完了すると、throw ステートメントによって開始された制御の転送が中断される可能性があることに注意してください。

finally ブロック内に戻る以外に、他にどのような方法がありますか?

私がしたいのは、例外が発生したときに例外をレベルアップすることだけですか?

これらの 2 つの方法は同じではありませんか?

TryCatch で例外が発生した場合は 1 レベル上にスローされ、NoTryCatch で例外が発生した場合は 1 レベル上にスローされます。

この質問は、ReSharper を使用して、try/catch ブロックが冗長であるため削除するよう提案されていることに気付いた後に発生しました。

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

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

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

Is there an elegant way to handle exceptions that are thrown in finally block?

For example:

How do you avoid the try/catch in the finally block?