試してみよう/最後に（キャッチせずに）バブルを例外にしますか？

Question

答えが「はい」であることはほぼ肯定的です。 Try Finallyブロックを使用してもCatchブロックを使用しないと、例外が発生します。正しい？

一般的な考え方はありますか？

セス

Answer 1

はい、絶対になります。 finallyブロックが例外をスローしないと仮定すると、当然、最初にスローされたブロックを効果的に「置き換える」ことになります。

Answer 2

一般的な考え方はありますか？

はい。 注意してください。 finallyブロックが実行されているとき、処理されていない、予期しない例外がにスローされたため、が実行されている可能性があります。つまり、何かがが壊れた、そして何かが全く予期しない何かが起きている可能性があります。

おそらく、最終的なブロックでコードを実行しないでください。 finallyブロックのコードは、依存するサブシステムが健全であると仮定するように構築されていても、実際には深く壊れている可能性があります。 finallyブロックのコードは状況を悪化させる可能性があります。例えば

、私は多くの場合、この種のものを参照してください。このコードの作者は、私は世界の状態を一時的に変異を作っています」考えている

DisableAccessToTheResource(); 
try 
{ 
    DoSomethingToTheResource(); 
} 
finally 
{ 
    EnableAccessToTheResource(); 
} 

を、私はに状態を復元する必要があります私が呼び出される前は何だったのか」しかし、これが間違っている可能性があるすべての方法について考えてみましょう。

最初に、リソースへのアクセスは、呼び出し元によってすでに無効にされている可能性があります。その場合、このコードはおそらく時期尚早にそれを再び有効にします。

第2に、DoSomethingToTheResourceが例外をスローした場合、リソースへのアクセスを可能にするために正しいことがありますか？リソースを管理するコードは、が予期せず壊れていますです。このコードでは、「管理コードが壊れている場合、は、他のコードが破損したコードをできるだけ早く呼び出すことができるので、恐ろしく失敗する可能性があることを確認しています。」これは悪い考えのようです。

第3に、DoSomethingToTheResourceが例外をスローすると、EnableAccessToTheResourceも例外をスローしないことをどのように知ることができますか？リソースの使用がクリーンアップコードに影響を与える可能性がありますが、元の例外は失われ、問題は診断するのが難しくなります。

私は、try-finallyブロックを使用せずに、このようなコードを記述する傾向がある：

bool wasDisabled = IsAccessDisabled(); 
if (!wasDisabled) 
    DisableAccessToTheResource(); 
DoSomethingToTheResource(); 
if (!wasDisabled) 
    EnableAccessToTheResource(); 

それはする必要がありますしない限り、今の状態が変異していません。今、発信者の状態は乱されていません。 DoSomethingToTheResourceが失敗した場合は、再度アクセスを有効にしません。何かが深刻に壊れていると想定し、コードを実行し続けることによって状況を悪化させる危険性はありません。可能であれば、発信者に問題に対処させてください。

だから、finallyブロックを実行するのは良い考えですか？最初に、例外が予想されるとき。たとえば、他の誰かがロックしているため、ファイルをロックしようとする試みが失敗する可能性があります。その場合、例外をキャッチしてユーザーに報告するのが理にかなっています。その場合、何が壊れているのかに関する不確実性は減少する。あなたは浄化することによって物事を悪化させることはまずありません。

第2に、クリーンアップするリソースが不足しているシステムリソースである場合。たとえば、finallyブロック内のファイルハンドルを閉じることは理にかなっています。 （「使用する」とは、もちろんtry-finallyブロックを書き込む別の方法です）。ファイルの内容が壊れている可能性がありますが、今はそれについて何もできません。ファイルハンドルは最終的に閉じられるので、遅くなくても早くなる可能性があります。