boost :: filesystem::existsを使用しているときに少し奇妙な状況に遭遇しました。準備ができていないか、メディアが入っていないドライブにファイルが存在するかどうかを確認しようとすると、basic_filesystem_errorがスローされます。bfs :: examplesのほとんどすべての使用法に関する限り、ドライブの準備ができていない場合は、ファイルが存在しないことを意味します。
この状態を適切に処理するために、try-catchで呼び出しをラップすることはできますが、少し面倒になり、コードが少し不格好になります。さらに悪いことに、フロー制御にbasic_filesystem_errorの特殊なケースを使用していることを意味します。つまり、その例外の別の理由が発生した場合、それを適切に処理できなくなります。
これが発生する一般的なケースは、ファイルがCDまたはDVDドライブに存在するかどうかを確認しようとした場合です。以前の私のコード:
if( bfs::exists( myFilePath ) )
{
...
}
になる:
bool fileExists( false );
try
{
fileExists = bfs::exists( myFilePath );
}
catch( bfs::basic_filesystem_error<bfs::path> e )
{
fileExists = false;
}
if( fileExists )
{
...
}
私は、既存のコードベースのいたるところにこの変更を加えるという考えにあまり夢中になりません。
try-catchをラップする別の関数を作成し、bfs :: exit呼び出しをそれで置き換えることを検討していますが、try-catchをそのように使用するのが良い考えであることにまだ満足していません。より重要で関連性のある例外的な条件を見逃しているため、私は扉を開いているようです。
関数の非スローバージョンのブーストを再コンパイルできることは承知していますが、それによって例外処理の問題が実際に回避されるとは思いません。
以前にリムーバブルメディアドライブでこの問題に遭遇したことがありますか?もしそうなら、どのようにしてそれを克服しましたか?