Right, you can't call the .Exists() method on a null object.Got it, thanks for answering. It felt like a dumb question but I stared at this for a few minutes and wondered how the statement could ever be true. I wasn't separating the existence of the object versus the existence of the file itself.
I don't work with raw files often and in general Apache and other 3rd parties have things like FileUtils but in Java File is a concrete class instantiated with the path. So yeah you'd need to call exists on it. But like I said some third parties have made interaction with files much more intuitive and convenient than the native api.Does Java not have static methods? In C# File.Exists is a static method meaning you don't instantiate any objects you just call File.Exists(file1) where file1 is just the path of the file. This will never throw a null exception, it will just return false if the file does not exist.
Java does have static methods but File just isn't implemented that way, you could just do if (new File("/var/myfile.txt").exists()) { do something } if you wanted to.Does Java not have static methods? In C# File.Exists is a static method meaning you don't instantiate any objects you just call File.Exists(file1) where file1 is just the path of the file. This will never throw a null exception, it will just return false if the file does not exist.
Seems like you have to instantiate the object anyway just to do an exists() check. The original code just didn't show where it was instantiated, but it was further up the chain otherwise he wouldn't be able to call exists() on it.That seems a bad way to do it, performance wise, since you'd have to instantiate another object to do anything with the file. Or is there some Java way to reference that object within the if() scope?
The cost of instantiating objects while we're discussing going to the hard drive to check if a file exists is bottling my mind. Instantiating objects takes picoseconds probably depending on what the constructor does, going to the file system will take orders of magnitude longer. How many objects we instantiate to do that is a completely worthless metric.I'm talking about the cost of 2 instantiations versus 1 for the same exists().
I was just saying if you wanted to do it the same way as the static check in C#, you could do it that way. Or, you could create a local File variable and stick the File reference in there to re-use if you're going to do that. Obviously you wouldn't want to call new File() over and over if you're doing multiple operations with the file. I was just answering how you could call it in a one-line way.Who cares about the relative cost, why write lazy code? It doesn't even save you any LoC.
Probably, but I think wasteful instantiated objects are probably not a very serious performance issue in any event. In CPU-performance driven apps/games etc that type of thing would be critical. In most "business" apps and webapps like what I have primarily worked on, managing your database and file system calls gets you 99% of your performance benefit.My bad, sorry for misinterpreting your intent. So as to not to completely waste this tangent, is this a common way to code? I see wasteful instantiated objects and it just annoys me to no end, even if the instantiation is comparatively minor.