这是我的代码：
public void ReadSomeFile(string filePath)
{
if (!File.Exists(filePath))
throw new FileNotFoundException();
var stream = new FileStream(filePath, ....)
.....
}
我是否应该自己抛出异常（请参阅File.Exists检查）？如果文件不存在，FileStream将已经抛出FileNotFoundException。这里有什么好的编程习惯？代码分析表明，我们应该验证参数。但是，如果我将该参数直接传递给另一个方法（我的代码或其他代码），并且该方法本身会引发异常，那么在我的代码中验证参数的好处是什么？
filePath看起来是否有效（即，绝对路径，或至少不包含Path.GetInvalidFileNameChars()）
Answers:
if (File.Exists(f)) { DoSomething(f) }（或其否定）是反模式。可以在这两个语句之间删除或创建该文件，因此以这种方式检查其存在意义不大。
除此之外，正如注释中指出的那样，尽管File.Exists()可能返回true，但是由于各种原因，实际打开文件仍然可能失败。因此，您将不得不重复错误检查并抛出文件的开头。
因为您不想重复自己，而是让代码保持DRY，只需尝试打开文件并new FileStream()抛出。然后，您可以捕获该异常，并根据需要重新引发原始异常或引发特定于应用程序的异常。
当然，调用File.Exists()是可以辩解的，但不能采用这种方式。
File.Open(f);抛出和捕获之间创建文件。问题较少是情况在您处理之前可能会有所改变（因为在失败情况下这几乎是不可避免的），而是您应该对错误进行一次检查以避免重复（并且无论如何都必须对错误进行检查）。（还请注意，在与某些文件系统对话时，成功打开并不意味着不会删除您的文件：因此，即使打开似乎起作用，即使失败也可能发生。）
您的方法被调用ReadSomeFile并将其filename作为输入，因此抛出a是合理的FileNotFoundException。由于无法通过捕获异常然后自己抛出异常来添加任何值，因此请让.NET抛出该异常。
但是，如果您的方法过去LoadData(databaseName)并且必须访问许多文件，则捕获异常并引发自定义异常可能很有价值，因为您可以将databaseName连同其他有用信息一起添加到异常中。
除了已经给出的答案之外，您还可以说这取决于您期望发生的情况。
如果要读取日志文件并且该文件不存在，是否要引发错误，或者仅引发空字符串（或空字符串数组）？
如果返回默认值（例如空字符串），我只需将函数的内容包装在try-catch（但仅用于预期的错误）中，然后在catch块中返回默认值，同时在块中返回实际内容try。
这将导致三种可能的情况：
FileNotFoundException-实际上，这只是在引发种族状况问题。您可以处理异常，让其传播或将其包装在您自己的异常中。这分别对应于“我知道该怎么办”，“我不知道该怎么办”和“我想在堆栈上更高级地处理”。