Should my method throw its own exception, or let .NET throw if a file doesn't exist?

Here is my code:

public void ReadSomeFile(string filePath)
{
    if (!File.Exists(filePath))
        throw new FileNotFoundException();

    var stream = new FileStream(filePath, ....)
    .....
}

Should I throw an exception myself (see the File.Exists check)? FileStream will already throw FileNotFoundException if the the file doesn't exist. What is good programming practice here? Code analysis says that we should validate our parameters. But if I am passing that parameter directly to another method (mine or someone else code) and that method will throw exception itself, then what is advantage of validating argument in my code?

if (File.Exists(f)) { DoSomething(f) } (or the negation thereof) is an anti-pattern. The file can be deleted or created in between those two statements, so it makes little sense to check its existence like that.

Apart from that, as pointed out in the comments, while File.Exists() may return true, the actual opening of the file can then still fail for a variety of reasons. So you'll have to repeat the error checking and throwing around the opening of the file.

As you don't want to repeat yourself but instead keep your code DRY, just attempt to open the file and let new FileStream() throw. Then you can catch the exception, and if you wish, re-throw the original or throw an application-specific exception.

Of course calling File.Exists() can be justified, but not in this pattern.

Your method is called ReadSomeFile and takes a filename as its input, therefore it is reasonable for it to throw a FileNotFoundException. As you cannot add any value by catching the exception then throwing it yourself, just let .NET throw it.

However if your method was LoadData(databaseName) and it has to access many files, catching the exception, and throwing a custom exception may be of value, as you could add the databaseName to the exception along with other helpful information.