Reputation: 4063
I have some some code which was written before I started here (sounds like a submission for The Daily WTF!) which loads an xml file for processing (the Throw line has been simplified to hide the identity of the culprit, otherwise its verbatim).
Try
docData.Load(strPath)
Catch oError As Exception
Throw New Exception("There is a load or parse error in the xml")
End Try
oFileInfo = New FileInfo(strPath)
strFileName = oFileInfo.FullName
oFileInfo = Nothing
strFileName
is used once more in the method, passed to another method
strPath
is used once more in the method, when deleting the file
From MSDN:
FullName: Gets the full path of the directory or file. (Inherited from FileSystemInfo.)
Surely then, that is simply returning what is already in strPath
and can be replaced with a simple
strFileName = strPath
Or even do away with strFileName
altogether and use strPath
throughout.
Or am I missing something? Does FileInfo.FullName
do anything else?
I did think it was a file exists check, but that has already been taken care of by the Try...Catch
around the XmlDocument.Load
and besides, File.Exists(strPath)
would be much simpler.
Upvotes: 1
Views: 8377
Reputation: 55427
What @Joe is saying is that technically strPath
could be a relative path. When you pass that into FileInfo
and retrieve the FullName
property it gets converted into an absolute path. Although you says that everything is UNC (and by that I'm assuming you also mean absolute paths) its possible that at one point this was called with relative paths. For instance this code will output c:\Users\...\bin\somefile.bin
Dim F As New System.IO.FileInfo("..\somefile.bin")
Trace.WriteLine(F.FullName)
Me.Close()
If you know that you'll always be dealing with absolute paths you can probably get rid of that code now.
Upvotes: 2
Reputation: 124696
FileInfo.FullName
will return the full path even if the input strPath is a relative path.
Upvotes: 3