問題タブ [try-catch-finally]

上記のコードでは、出力は「2」です。私が期待していたのは、何も印刷されるべきではないということでした。ここで「休憩」は正確に何をしますか？説明してください。ありがとう

私たちのシステムには抽象クラスがあり、それをBasicActionと呼びましょう。これには、いくつかの抽象メソッドが含まれています。それらの中で最も重要なものはexecuteと呼ばれます。JSPページからのリクエストを処理します。メインハンドラーは次のように機能します。

これで、すべてが正常に見えますが、基本的にすべての派生ハンドラーは同じコードを実装します。

私が持っているすべてのハンドラーにそのようなブロックを書くのは少し面倒なようです。ここでは、各ハンドラーの入口/出口ポイントを想定どおりに模倣していないようです。ここで必要なのは、BasicActionでcreateManagersとdisposeManagersという2つの抽象メソッドを定義することだと思います。その場合、メインハンドラーは次のようになります。

その後、各派生アクションハンドラーは次のように定義できます。

どちらのアプローチを使用するのが良いか-各ハンドラーでtry-catch-finallyを使用するか、標準の入口/出口ポイントを使用します。

ScheduledExecutorServiceJEE環境でのタスクスケジューリング用に取得しました。これらのタスクの中には、中断されたときにリソースを開いたままにするものがありScheduledExecutorService.shutdownNow()ます (たとえば、Lucene のようなサードパーティのライブラリでファイルを開くなど)。

スレッドはそれ自体で実行を停止できない場合があることを知っています。スレッドを停止するために使用する必要がある方法は、割り込みフラグをチークしてメソッドの実行を停止することです。スレッドがブロックされている場合 (例: wait()、sleep() など)または、割り込み可能なチャネルで何らかの IO 操作をThread.interrupt()行うと、InterruptedException上昇します。どちらの場合も、finally ブロックを実行する必要があります。http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Thread.html#interrupt%28%29を参照してください。

明らかに、Task クラスに非常に適切に実装された finally ブロックを使用してリソースを解放しようとしましたが、一部の環境 (CentOS など) では、スレッドが中断されたときに finally ブロックが実行されません。そして、公式のJavaドキュメントで次の非常にクールなメモを見つけました。

注: try または catch コードの実行中に JVM が終了すると、finally ブロックが実行されない場合があります。同様に、try または catch コードを実行しているスレッドが中断または強制終了された場合、アプリケーション全体が続行されても、finally ブロックが実行されない可能性があります。

したがって、リソースの解放を強制する Task クラスに public メソッドを実装するために、スケジュールされたすべてのタスクへの参照が必要です。からタスク クラスへのこれらの参照を取得できますScheduledExecutorServiceか? または、私の問題をより良い方法で解決するためのクールなアイデアはありますか?

最初の解決策: 包む!

のラッパー クラスを作成し、ScheduledExecutorService次のようなプロパティを追加します。

これにより、任意の Runnable オブジェクトに直接、またはScheduledFutureそれに関連するオブジェクトにアクセスできます。ラッパーのインスタンス化のためにScheduledExecutorService、メソッドからを取得Executors.newScheduledThreadPool()してラッパーに渡すことができます。

別の解決策: 拡張してください!

を拡張しScheduledThreadPoolExecutor、IdentityHashMap プロパティを追加し、ジョブをスケジュールまたはキャンセルするすべてのメソッドを上書きして、Map から参照を追加/削除します。

両方のソリューションの問題？

ラッパーまたは拡張クラスの呼び出し元がオブジェクトを受け取った場合、 「カプセル」をバイパスしてSchedulerFuture<?>、メソッドでジョブをキャンセルできます。SchedulerFuture<?>.cancel()ラッパーを使用すると、参照を呼び出し元に渡さないようSchedulerFuture<?>にすることができますが、拡張クラスではできません (拡張クラスで独自のメソッドを作成すると、ラッパーと同じ結果が得られますが、非常に紛らわしい方法になります)。 .

エレガントな解決策: 独自のスケジューラー! それを指摘してくれたKajに感謝します...

1. を拡張してメソッドScheduledThreadPoolExecutorを上書きする decorateTask()
2. インターフェイスRunnableの 1 つの実装で を 装飾するScheduledFuture
3. cancel()実際にスレッドをキャンセルするだけでなく、Runnableオブジェクトを操作してリソースの解放を強制するカスタム メソッドを 1 つ実装します。

詳細とコード例については、私のブログ投稿を確認してください!!!

上記のコードサンプルでは、​​2つの関数ReadFileとがありReadCSVFileます。
でReadCSVFile、タイプFileNotFoundExceptionの例外が発生します。これは、catch（FileNotFoundException）ブロックでキャッチされます。しかし、この例外をスローしてReadFile関数のcatch（FileNotFoundException）にキャッチすると、catch（FileNotFoundException）ではなくcatch（Exception）ブロックにキャッチされます。さらに、デバッグ中、exの値はObjectNotInitializedと表示されます。内部例外を失うことなく、または少なくとも例外メッセージを発生させることなく、呼び出された関数から呼び出し元関数のcatchブロックに例外をスローするにはどうすればよいですか？

Java では、try-catch-finally の try ブロック内に return ステートメントを挿入すると、finally ブロックは実行されませんか?

Eric Lippert がこの記事で説明しているように、句yield return内では は許可されていません。try/catch

IEnumerator自分自身を手で書かなくても、このようなものを得ることができる良い方法はありますか?

私はPythonで大きなバッチタイプのスクリプトを書いていますが、例外が発生したかどうかに関係なく、最後にクリーンアップを行う必要があります。これを行うには、メインプログラムをtryブロックに配置し、クリーンアップをfinallyブロックに配置するだけです。

これはうまくいくようですが、私の質問は、発生する可能性のある例外をどのように出力するかです。現在、それらを無視して、finallyブロックにジャンプします。

保留中のタスクのスケジュールテーブルからのポーリングとそれらの実行を管理するために、Windowsサービスの基本クラスを構築しています。

Windowsサービスは、を使用しSystem.Timers.Timerてスケジュールのテーブルポーリングを開始しています。

ThreadPool.SetMaxThreadタイマーを初期化する前に、を10に設定しています。

タイマーによって呼び出されるデリゲートメソッドは、実行中のスレッドのカウントを保持するため、OnStop（）メソッドで使用して、サービスを破棄する前に各スレッドが完了するのを待つことができます。

多くの場合、Windowsサービス管理コンソールからサービスを停止しようとしても、サービスは停止しません。デバッグしてOnStop（）メソッドにブレークポイントを追加すると、numberOfRunningThreadsが0より大きい数（多くの場合10より大きい！）でスタックしているためではないことがわかります。実行中のタスクはなく、その数に永久に留まります。

ThreadPool.SetMaxThreadsまず、10に制限する必要があるにもかかわらず、その数が10を超える可能性があることを理解していませんか？

次に、スレッドの最大数を設定しなかった場合でも、PollWrapperのfinallyブロックが最終的にカウントを0に戻すことを期待します。カウンターが0より大きいままの場合、finallyブロックでは説明できません。実行中ですよね！？それはどのように可能ですか？

そして最後に、ポーリングを固定数（.NET 3.5）の可能な同時実行スレッドの数に制限する別の方法を提案しますか？

どうもありがとう。

アップデート：

再入可能性とSetMaxThreadに関するYahiaのコメントを読んだ後、PollWrapperを変更して、生成される実行中のスレッドの最大数を常に制限するようにしました。投票が再入可能であることを確認します。

ファイルに対して実行する必要のあるすべての操作が成功しなかった場合（つまり、例外が発生した場合）は、ファイルを削除する必要があります。を使用するのと同じくらい簡単で、ファイルを削除してから例外を再発生させることもできますが、その場合、なんらかの理由でファイルをexcept句で削除できないと、元の例外が失われます。

私が思いついた最高のものはこれです：

より良い、よりPythonicなアプローチを知っている人はいますか？

私の理解では、try が入力された場合、 finally 句は*常に* 実行する必要があります。

予想される出力は、8 行目までに単独で出力される x ごとに、'Finally x' が出現することです。

出力例:

他のプロセスで実行する必要がある追加の作業があるにもかかわらず、1 つのプロセスを終了する例外が親プロセスと兄弟プロセスを終了するようです。

なぜ私は間違っているのですか？なぜこれが正しいのですか？これが正しい場合、マルチプロセス Python でリソースを安全にクリーンアップするにはどうすればよいですか?