文件系统是易失性的。这意味着您不能相信一个操作的结果对于下一个操作仍然有效，即使它是下一行代码。你不能只说if (some file exists and I have permissions for it) open the file，你不能说if (some file does not exist) create the file。你的结果总是有可能if条件将change在代码的两部分之间。这些操作是不同的：不是原子的。
更糟糕的是，问题的本质意味着，如果您想进行此检查，您很可能已经担心或意识到文件可能会发生您无法控制的事情。开发环境的性质使得该事件在测试期间不太可能发生并且很难重现。所以你不仅有一个错误，而且这个错误在测试时不会出现。
因此，在正常情况下，最好的做法是不要尝试检查文件或目录是否存在。相反，将开发时间投入到处理文件系统的异常上。无论如何，您都必须处理这些异常，因此这可以更好地利用您的资源。尽管异常很慢，但检查文件是否存在需要额外的磁盘访问，并且磁盘访问是much慢点。我什至有一个投票很好的answer在另一个问题中达到这个效果。
但我有一些疑问。例如，在 .Net 中，如果那真的是always确实如此，.Exists()方法一开始就不会出现在 API 中。还要考虑您的场景expect您的程序需要创建文件。我想到的第一个例子是桌面应用程序。该应用程序将默认的用户配置文件安装到其主目录，并且每个用户第一次启动该应用程序时，都会将此文件复制到该用户的应用程序数据文件夹中。它期望该文件在第一次启动时不存在。
那么什么时候可以提前检查文件是否存在（或其他属性，如大小和权限）？期待第一次尝试失败而不是成功是否是一个足够好的经验法则？
File.Exists 方法主要用于在您不打算打开文件时测试文件是否存在。例如，测试锁定文件是否存在，该文件的存在会告诉您一些信息，但其内容并不重要。
如果要打开该文件，则无论之前调用 File.Exists 的结果如何，都需要处理任何异常。因此，一般来说，在这些情况下调用它没有真正的价值。只需在 open 方法中使用适当的 FileMode 枚举值并处理任何异常，就这么简单。
编辑：尽管这是用 .Net API 表达的，但它是基于底层系统 API 的。 Windows 和 Unix 都有使用等效于 FileMode 枚举的系统调用（即 CreateFile）。事实上，在.Net（或Mono）中，FileMode 值只是传递给底层系统调用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
