gpt4 book ai didi

c++ - boost::filesystem::exists 真的应该为没有媒体的可移动媒体设备抛出异常吗?

转载 作者:塔克拉玛干 更新时间:2023-11-02 23:36:19 24 4
gpt4 key购买 nike

我在使用 boost::filesystem::exists 时遇到了一些奇怪的情况。如果您尝试检查驱动器上是否存在未就绪或没有介质的文件,则会抛出 basic_filesystem_error。就我对 bfs::exists 的大多数用途而言,如果驱动器未准备好,则意味着该文件不存在。

我可以用 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::exist 调用,但我仍然不满意以这种方式使用 try-catch 是个好主意.似乎我正在为错过更重要和相关的特殊条件打开大门。

我知道您可以为函数的非抛出版本重新编译 boost,但我认为这并不能真正避免我的异常处理问题。

以前有没有人在使用可移动媒体驱动器时遇到过这个问题,如果遇到过,您是如何克服的?

最佳答案

根据文档,exists(file_status s) returnsstatus_known(s) && s.type() != file_not_found”。

The documentation also states that :

If the underlying file system reports an error during [file_status] attribute determination:

  • If the error indicating that p could not be resolved, as if by POSIX errors ENOENT [i.e., not found] ... return file_status(not_found_flag).

在我看来,抛出异常并不是预期的行为。 (当您创建 status 对象时,它的状态是已知的,并且该状态是 not_found)。

但是,文档继续说:

[Note: The effect of this behavior is to distinguish between knowing that p does not exist, and not being able to determine the status of p. This distinction is important to users. --end note]

这意味着库确实打算区分“文件不存在”和“我无法确定该文件不存在”。您可能希望联系库的作者以获得更清晰的声明。

但是,测试文件是否存在是一种竞争条件:操作系统查找时文件可能已经存在,但不能保证它会继续存在;同样,操作系统查找时该文件可能不存在,但不能保证它会继续不存在。 The race condition can have security implications .

而是打开文件,然后查看其属性。文件打开后,操作系统会就哪些内容会发生变化以及哪些不会发生变化做出某些保证。

关于c++ - boost::filesystem::exists 真的应该为没有媒体的可移动媒体设备抛出异常吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1065969/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com