Well, the title says it all. When passing a file name to a method, should I use a FileInfo object or a plain file name (string)? Why would I prefer one to the other?
Some of my colleagues like to write method like this:
Is it better than:
Thanks!
I'd usually just use a string - it's simpler in most cases. Otherwise you're likely to just create a new FileInfo from the string in the first place.
If you're creating the method, you could always provide overloads to allow both.
Of course, if you know that where you're intending to call it, you usually have a FileInfo rather than a string, that's a different matter.
I can see your colleagues' point of view - in some ways a FileInfo is a "cleaner" way of expressing the parameter. I think string is the more pragmatic approach though :)
I would say it depends :) Many static file operations on the class File allow a number of things with the filename. The abstraction of a File is not that often useful in the .NET Framework, so I am biased towards using a string and denoting in the argument name what it is.
Typically I would pass the string. However, you could overload the method to make everyone happy.
The difference is primarily that there is a little bit of checking going on; the FileInfo constructor does some checking for a null or clearly invalid parameter. There are a few other things it does; taking a FileInfo basically just puts the onus of handling the exceptions from the FileInfo constructor on the calling code, as opposed to your code.
Here's the MSDN reference for the FileInfo constructor that shows what the constructor can throw:
http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx
I would follow the convention of using Steams. This is how I see most I/O performed. It makes sense to me:
void Export(string s)
{
Stream fs = new FileStream(s); //think this is correct
Export(fs);
}
void Export(Stream s)
{
s.Write ( ... );
...
}
I agree, FileInfo has never been that useful to me. stick with string or use stream which can be FileStream, MemoryStream, etc.
If you're working on code involving these colleagues, I would use FileInfo. It really doesn't matter much but writing code the way others expect it reduces maintainence, raises consistency, and generally makes people happy.
I will point out that I dislike the idea of using FileInfo for the sake of putting the onus of checks for validity on the calling function, as pointed out by McWafflestix. If something breaks between the calling function and the function that was called, it won't be caught. It won't necessarily be caught if you use a string...but at least it makes it clear where the problem can happen. And you'll want to catch such exceptions in the called method anyways. Surely you aren't going to open the file and start reading/writing until you're in the actual function (if you are, FileInfo and string are probably both the wrong choice, but Stream makes sense, as TheSean suggests).
A FileInfo does do more to show the intent of the data type than a string. And that's almost always a good thing. However, there's certainly plenty of precedent for passing a file name as a string, including most of the .NET framework itself. A file name IS a string. Presumably, you'd have the caller use the FileInfo object to force the calling code to validate the file name (i.e. handle the exception) rather than burdening yourself with passing back the exception.
Certainly, including a method overload would remove all doubt, so long as you're validating the file name being passed in.
As usual, it depends. In all but the most basic of cases, I'd say using FileInfo gives you a lot of benefits with almost no negatives. Strict OO dogma would say that information about a file (path, creation date, modified date, etc) should be encapsulated within a class like FileInfo. This will allow you more flexibility if down the road you need more complex behavior. If you write your code against FileInfo, it will almost always be cleaner and less bug-prone if you need to make changes.
If you absolutely can't think of a scenario where you'd need more complex behavior, and it's going to really throw you off, go ahead and just use a string.
So this will be better if MS will provide Path object :) or you can make it yourself, especially if this is your internal code. In this way you will not need to check your PATH arguments every time you will work with them. I often has many structs that represent different stings, NonNullString, IdString(case insensitive), I believe that this makes code simply.