このシチュエーションではSystem.Exceptionを使用するのが適切でしょうか？

Question

通常、System.Exceptionを使用するのに悩まされましたが、これが私の唯一の選択肢であるかどうかは疑問です。

私は、このシナリオに

のパーミッションチェックが行われ、編集のための

1. ユーザー要求タスクを持っています。
2. dbからのすべての正常なタスク行が取得された場合
3. タスクの更新がコミットされ、列がロックされていると更新されます。
4. 日付を現地時間に変換するために、このタスクにタイムゾーンのものが適用されます。
5. タスクがユーザーに表示されます。

したがって、手順1〜4の間に何か問題が発生しても、ロックされていないため、タスクは良好です。ただし、手順5で失敗し、ユーザーにタスクを表示できない場合、ファイルはロックされ、スケジュールされたジョブが実行されるまでロックされ、ロックされたファイルがロックされないように強制されます。

一時的に失敗した可能性があり、次にファイルを要求したときに再び機能する可能性があるので、ちょっと理想的ではありません。しかし、今では、自動的にロックが解除されるまで（他のすべての加入者と同じに）X分待つ必要があります。

私の最初の考えは最終的にはステートメントを使用していましたが、これは何に関係なく常に実行されるので、ファイルが今ロックされていると言うことを理解できませんでした。

ファイルがロックされていますが、何かが間違ってロックを解除しました。例外が発生したときにのみ実行される文がC＃にあったといいでしょう。

私の唯一の考えは例外があります。もし何か起これば、そこではロックが解除されます。唯一のケースは、データベースがダウンしている場合にロックを解除しようとするポイントがSQl例外である場合ではありません。

もちろん、私はelmahを使用してエラーをログに記録し、より良い例外タイプをゆっくりと追加します。

他にも優れたアイデアはありますか？

Answer 1

完璧を善の敵にすることはできません。このシナリオでは、一般的な例外をキャッチするのは問題ありません。より特定の例外タイプを捕捉して回復できる場合は、それを実行します。しかし、地獄の回復計画はすべて大丈夫ですが、賞賛に値するものではありません。

Answer 2

キャッチSystem.Exceptionはスレッドの先頭であり、どのような状況でもプログラムをクラッシュさせたくない場合は受け入れ可能です。一般的に、System.Exceptionをキャッチするのは悪い考えです。なぜなら何らかのエラーが発生する可能性があるからです。つまり、予期せぬことが起こったときには、スレッドの先頭に泡が入り、System.Exceptionをキャッチし、デバッグのためのinfoなど。

タイムゾーン変換を処理する手順5で「何か悪い」と心配しているため、特定の例外やクラスのクラスが発生する可能性があります。適切にアンロックする。

また、ロックされたファイルを検出してロックを効果的に強制するスケジュールされたタスクを作成できることが明らかになっているので、finallyブロックで同じロジックを使用できませんか？例えばロックされている場合はロックを解除し、それ以外の場合はロックを解除します。