C/C++ なんかを扱っていると事前確認が重要なことが非常に多いです。
char[10] へ 10文字以上の入力がくると buffer overflow しますね。ただ、これは private な memory の話です。
File 操作を行うときは話が別です。File というものは他の process や thread から自由に扱えるわけです。先ほどの private memory の話とは違い確認した後に状態が変化している可能性があります。連続した処理でも途中で別の thread が実行される可能性がある以上、どうしても変化する可能性があるのは否定できないでしょう。
このことは file 操作に限った話ではありません。その application (thread) の外部から変更されるすべてのものに対して当てはまります。
このような場合にはどうするか？
一般解としては、先に書き込みを lock してから確認を行い、そのあとで処理を行いますね。その後に lock を解放。
ちょっとまった！今回の話は file です。対象を lock するなら、事前にその file の事前確認しないと意味無くない？って感じに無限 loop しちゃうでしょう？
ということで、そもそも file の存在確認など不要というのが私の意見です。
一般的な file 操作は Win32 API なら戻り値で、.NET Framework では例外で成功したか結果を返しますね。いきなり操作を実行して、それで判断すればいいのです。
ちなみに例外を発生させるような API を利用していて、例外を発生させると performance が落ちるので、performance tuning のため事前に確認を行うべきだという意見もよく耳にします。ですが、その意見を口にするならこれはあくまで performance tuning が目的であり、存在確認自体はその結果が保障されていないということをあわせて教えるべきだと思います。
# 個人的には、よほど performance が求められる場合でもない限り行うべきではないと思ってます。Performance が落ちる可能性があるのは異常系が主になりますし、そこまで著しく落ちるものでもないことが多いでしょうから。ついでに正常系の performance が若干落ちますので。
なお、UNIX 系の OS ではここら辺をちゃんと抑えていないと TOCTOU (time of check - time of use) 競合における脆弱性となりうる場合があります。
セキュアなプログラマー: 競合状態を防ぐ