So, what is so wrong about simply calling FileLen() to check if the file exists, or if you also want to distinguish between Files/Directories using GetAttr to check the directory bit ? Why do you have to go all the way to this monster of code which even hardcodes lists of errors (why do you care which error it is?) ?
Your code sample renames the file, then globs anyway (when dir$ by itself can also be used to check existence). It looks too convoluted, and I cannot imagine why it needs to be so.
What is exactly the corner case that you want to avoid -- and if such case really exists, why are you so sure the File.Exists() implementation would not fall into the same pit trap, considering it also simply uses the metadata?
Disclaimer: I'm only familiar with VBA, not VB itself. But these file metadata functions definitely already exist in 95's VB5. (EDIT: Actually 97's. Maybe the problem is these functions did not exist in earlier VBs? But I would find it hard to imagine you could not check a file's size).
The sample code smells even in the trivial-case checks. E.g. Right$(_, 1) will only return a 1-char string at most, yet it tries to compare it with 2, 3 len strings. I didn't check any further than that.
To elaborate.. just what is wrong with simply doing the following?
Function FileExists(Filename) As Boolean
On Error Resume Next
FileExists = (GetAttr(Filename) And vbDirectory) = 0
End Function
It's not 2 lines, but it's 4, including function header. All functions used are available at least since 16-bit VB3. Is this what you call "a workaround and a hack?". It's practically the same thing .NET is doing for File.Exists() (or at least the current one -- dunno what .NET 1 was doing), so I cannot think of any gotchas that would affect this but not File.Exists.
Another way, use Dir by itself. This is even mentioned in the VB docs...
FileExists = Dir(Filename) <> ""
3 lines. It also ignores directories. Sure, this has problems with wildcards, but so does your example, and that's another oneliner to fix, using Replace$ (as wildcards are not legal characters in filenames in win32, either way). And if Dir("\") returns true for some reason, I guess that's a runtime bug, which is pretty valid criticism, even if a bit of a corner case (who really wants to check if "\" exists?). I would prefer the first version anyway.
I still stand by my original point that this is a very poor example, since there are a million ways check for a file's existence, many using only builtin functions of the language. You can certainly find nigh-overcomplicated ways to do so, apparently even on books, but ... why? Not a fan of cargo-culting like this; it tends to create Cherteston's fences.
Many languages also lack a direct "File_Exists" function (e.g. Lua comes to mind) since it's about the most trivial thing to implement (and a magnet for TOCTOU issues). Or even if they do come with such function, it does not distinguish directories from files (e.g. Tcl). I hardly think the lack of a "file_exists" function discriminates anything in language design, modern or otherwise.
GP complains that there is no direct function for "file exist". And technically there is not on Tcl either because file exists cmd will return true for directories. You can trivially build your proc that specifically checks for files (it will likely use isfile) but that is exactly the point of my comment. I have shown how do that for VB and it is not far from a one liner.
Presence/absence of a file exists function is a very poor example. If the language didn't allow you to check e.g. if a file was a directory or not, then GP might had have a point. But this is not the case.
There's nothing wrong with [file isfile $filename] either. As I'm saying there's a million of oneliners for it.
I am not sure if I'm getting my point clear. I'm presuming you are trying to defend that yes, you can check if a file exists in Tcl, even if there's no specific function for it, but that is, again, exactly my point. Like what you're doing, I've shown many ways to do it in VB.
I guess the fact that someone needs to nitpick me in exactly the same way I was nitpicking the GP is quite the proof that the analogy works perfectly...
Your code sample renames the file, then globs anyway (when dir$ by itself can also be used to check existence). It looks too convoluted, and I cannot imagine why it needs to be so.
What is exactly the corner case that you want to avoid -- and if such case really exists, why are you so sure the File.Exists() implementation would not fall into the same pit trap, considering it also simply uses the metadata?
Disclaimer: I'm only familiar with VBA, not VB itself. But these file metadata functions definitely already exist in 95's VB5. (EDIT: Actually 97's. Maybe the problem is these functions did not exist in earlier VBs? But I would find it hard to imagine you could not check a file's size).
The sample code smells even in the trivial-case checks. E.g. Right$(_, 1) will only return a 1-char string at most, yet it tries to compare it with 2, 3 len strings. I didn't check any further than that.