Should the method use FileInfo or a simple file name when passing a file name?
Well, the title says it all. Should the method use a FileInfo object or a simple filename (string) when passing a file name? Why should I give preference to another?
Some of my colleagues like to write a method like this:
- void Export (FileInfo fileInfo)
This is better than:
- void Export (string fileName)
Thanks!
a source to share
I usually just use it string
- in most cases it's easier. Otherwise, you will probably just create a new one FileInfo
from the string in the first place.
If you create a method, you can always provide overloads to allow both.
Of course, if you know that where you are going to call it, you usually have it FileInfo
, not string
that is another matter.
I see the point of view of your colleagues - in a sense, it FileInfo
is a "cleaner" way of expressing a parameter. I think that string
's a more pragmatic approach :)
a source to share
The difference is primarily that there is a little validation going on; the FileInfo constructor performs some validation on a null or explicitly invalid parameter. There are a few more things that he does; taking FileInfo basically just puts the burden of handling exceptions from the FileInfo constructor in the calling code as opposed to your code.
Here's the MSDN link for the FileInfo constructor that shows what a constructor can create:
http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx
a source to share
If you are working on code with these colleagues, I would use FileInfo. It really doesn't matter much, but writing your code the way others expect it decreases support, increases consistency, and generally makes people happy.
I'll point out that I don't like the idea of using FileInfo
to hold them accountable for the validity of the caller as pointed out by McWafflestix. If something breaks between the calling function and the called function, it won't get caught. It won't necessarily get caught if you're using a string ... but at least it makes it clear where the problem might be. And you will want to catch such exceptions in the called method anyway. Of course, you are not going to open the file and start reading / writing until you are in a valid function (if you are, FileInfo and string are probably the wrong choice, but Stream makes sense, as TheSean suggests).
a source to share
FileInfo does more to show the intent of a data type than a string. And that's almost always a good thing. However, there are many use cases for passing a filename as a string, including the .NET framework itself. The file name is a string. Presumably, you should use the caller's FileInfo to force the caller to check the filename (i.e. handle the exception), rather than burden yourself with throwing an exception.
Of course, including method overloading will remove all doubts as long as you validate the passed filename.
a source to share
- The string is not PATH. So a string is not the best way to represent a path.
- FileInfo is also not PATH, semantically it represents FILE.
So, it will be better if MS provides the Path object :) or you can do it yourself, especially if this is your internal code. This way you don't need to check your PATH arguments every time you work with them. I often have a lot of structures that represent different bites, NonNullString, IdString (case insensitive), I find this makes the code simple.
a source to share
I followed the Steams convention. This is how I see most I / O. This 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 so useful to me. stick to string, or use a stream, which could be FileStream, MemoryStream, etc.
a source to share
As usual, it depends. In all but the most basic cases, I would say that using FileInfo gives you a lot of benefits without almost any negatives. Strict OO dogma says that information about a file (path, creation date, modified date, etc.) should be encapsulated in a class such as FileInfo. This allows you to be more flexible if you need more complex behavior along the way. If you write your code against FileInfo, it will almost always be cleaner and less error prone if you need to make changes.
If you absolutely can't think of a scenario where you need more complex behavior and it really throws you off, go ahead and just use a string.
a source to share