Issue
I have java code that supposed to delete my existing file in my device but it does not work I don't why. It keep returning false when I try to use the .delete() function.
Here's my code, I already closed all the buffered and writer but it still not working
File saveFile = new File("save.txt");
File saveTemp = new File("temp.txt");
File playerFile = new File(player.username + ".txt");
String currentLine;
try {
FileWriter fw = new FileWriter(saveTemp, true);
BufferedWriter bw = new BufferedWriter(fw);
PrintWriter pw = new PrintWriter(bw);
FileReader fr = new FileReader("save.txt");
BufferedReader br = new BufferedReader(fr);
while((currentLine = br.readLine()) != null)
{
if (!currentLine.equals(player.username))
{
pw.println(currentLine);
}
}
pw.flush();
pw.close();
fr.close();
br.close();
bw.close();
fw.close();
saveFile.delete();
playerFile.delete();
File dump = new File("save.txt");
saveTemp.renameTo(dump);
} catch (Exception e) {
e.printStackTrace();
}
Solution
The java.io.File
API is obsolete. That means it is deprecated (you should stop using it), but, given that it is core API, 'deprecated' as a term specifically used in core means 'sometime somewhat soon, this will not work whatsoever', and java.io.File
isn't that - it'll work 10 years from now. But you still shouldn't use it. There are fundamental issues to its design that means it's a flawed API and it won't (cannot) be fixed.
One of its many flaws is that it is un-java-like in how it conveys errors to you. Weirdly, most of the File
API itself does not throw exceptions when things go wrong. Instead, it returns wonky things.
For example, file.list()
returns an empty array if you run that on an empty directory, but returns null
if it can't do the job (for example, the dir doesn't exist, or it's a file and not a dir, or, the java process doesn't have read rights). Similarly, delete()
does not throw an exception. Instead to indicate failure it returns false
. This is not only un-java-like, it also means it is not possible to know why delete()
doesn't work. Access rights issue? File doesn't exist? Who knows.
The simple conclusion is that you should always be checking the return value of anything you do to a j.i.File
object, but that's taking a shortcut. The true fix is to stop using it.
The new API also has problems but far fewer. It's also not obsolete/deprecated-in-the-english-dictionary-sense: This is how a state of the art java app should be interacting with files. You find it in the java.nio.file
package.
Unlike the j.i.File
API, this one does throw exceptions when things go wrong, and those exceptions tell you, both program-checkable (a hierarchy of types, such as NoSuchFileException
if you want to specifically react to such an issue), and human-checkable, in that the messages of these exceptions explain in english what's wrong.
Secondarily, you MUST close objects-that-represent-system-resources safely and your code does not do that. There's the handy try-with syntax that makes that easy, so let's do that too!
Thirdly, you are flushing-then-closing. This is pointless; close()
already implies flush, there is no reason to ever call flush() before close, it just clutters up your code. In fact, with try-with there's no need to close whatsoever.
Thus:
Path tempFile = Paths.get("temp.txt");
Path saveFile = Paths.get("save.txt");
try (
Writer fw = Files.newBufferedWriter(tempFile, StandardOpenOption.APPEND);
BufferedReader br = Files.newBufferedReader(saveFile);
) {
String line;
while ((line = br.readLine()) != null) {
if (line.equals(player.username)) continue;
fw.write(line);
fw.write("\n");
}
}
Files.delete(saveFile);
Files.move(tempFile, saveFile);
Answered By - rzwitserloot
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.