我经常使用File.Exists之类的库函数在打开文件或执行其他操作之前检查文件是否存在。多年来，我在实践中一直很幸运，但我想知道这是否是一种深思熟虑的模式。
任何IO调用（例如文件系统读取）都可能由于多种原因而失败。路径字符串可能错误或文件实际上不存在，您可能缺少权限，其他人可能具有阻止您的锁。您甚至可以让另一个进程或网络上的另一个用户在毫秒内在File.Exists和Open之间移动文件。
即使您从File.Exists获得成功的结果，您实际上仍然应该将实际的open语句放在try块中，以处理其他可能的失败模式之一。如果我正确地考虑了这个问题，则使用File.Exists而不是Try会使您误以为是安全感（因为我确信过去有时会这样做）。
所有这些使我听起来似乎应该放弃File.Exists并更改我发现的任何仅使用Try ... Catch模式的现有代码。这是一个明智的结论吗？我意识到框架的作者只是在这里供我们使用，但这并不能自动使它成为实践中的好工具。
最佳答案
我认为答案完全取决于您使用File.Exists的特定原因。
例如，如果您要检查某个文件路径中文件的到达，则File.Exists可能很容易成为适当的方法，因为您不在乎不存在的原因是什么。
但是，如果您要处理最终用户要求的文件（即，请导入此excel文件），则需要确切知道文件失败的原因。在这种特定情况下，File.Exists并不是正确的方法，因为在检查文件和打开文件之间，文件的存在可能会发生变化。在这种情况下，我们尝试在处理文件之前打开文件并获得对其的锁定。 open方法将抛出与您正在处理的特定情况相适应的错误，以便您可以向用户提供有关该问题的更准确的信息（即，另一个进程已锁定文件，网络文件不可用，等等）。
关于c# - File.Exists是否有害？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26112624/