我的方法应抛出自己的exception，或让.NET抛出，如果文件不存在？
这是我的代码：
public void ReadSomeFile(string filePath) { if (!File.Exists(filePath)) throw new FileNotFoundException(); var stream = new FileStream(filePath, ....) ..... } 我应该自己抛出一个exception（请参阅File.Exists检查）？ 如果文件不存在， FileStream将会抛出FileNotFoundException 。 这里有什么好的编程习惯？ 代码分析说我们应该validation我们的参数。 但是，如果我直接将该parameter passing给另一个方法（我的或其他代码），并且该方法本身会引发exception，那么在我的代码中validation参数有什么好处？
if (File.Exists(f)) { DoSomething(f) } （或否定）是反模式。 这个文件可以在这两个语句之间被删除或创build，所以检查它的存在是没有意义的。
除此之外，正如在注释中指出的那样，虽然File.Exists()可能返回true，但由于各种原因，文件的实际打开仍然会失败。 所以你将不得不重复错误检查，并抛出文件的开头。
因为你不想重复自己，而是保持你的代码干，只是试图打开文件，并让new FileStream()抛出。 然后你可以捕获这个exception，如果你愿意的话，可以重新抛出原始的或抛出一个特定于应用程序的exception。
当然，调用File.Exists()可以certificate是正确的，但不是这种模式。
你的方法叫做ReadSomeFile并且把一个filename作为它的input，因此抛出一个FileNotFoundException是合理的。 因为你不能通过捕获exception来添加任何值，然后自己抛出它，让.NET抛出它。
但是，如果您的方法是LoadData(databaseName)并且必须访问许多文件，捕获exception并引发自定义exception可能是有价值的，因为您可以将databaseName添加到exception以及其他有用的信息。
除了已经给出的答案之外，还可以说这取决于你期望的结果。
如果你想读取一个日志文件，而不存在，你想抛出一个错误，或者只是一个空的String（或空string数组）？
如果返回一个默认值（比如一个空string），我会简单地将函数的内容包装在一个try-catch （但仅用于预期的错误），并返回catch块中的默认值，同时返回try块中的实际内容。
这会留下三种可能的情况：
- 文件的内容被返回;
- 返回默认值，因为发生了预期的错误;
- .NET引发错误，因为你没有捕获到这个特定的错误。
让正确的方法试图打开文件，而你不知道完整的文件名，像特殊文件名（如设备文件和UNCpath ）的东西：
在某些情况下，其他文件方法可能会失败，但打开文件是成功的。
特殊文件名的一些例子是：
- CON
- NUL
- COM1，COM2，COM3，COM4
- \\服务器\共享\ FILE_PATH
- \\ teela \ admin $ \ system32（到达C：\ WINNT \ system32）
- C：.. \ FILE.TXT
- \\。\ COM1
- ％TEMP％
- 和更多…
