Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du hast dir die Antwort auf deine Frage doch schon selber geschrieben. Laut den Docs wirft delete nur eine SecurityException, die eine RuntimeException ist, und somit nicht abgefangen werden muss.
Und anstatt der IOException gibt es den Rückgabewert, um den Erfolg der Operation abzuprüfen.
Die Rückmeldungen die die Klasse Files über die Exceptions gibt, sind allerdings um einiges genauer, was das Programmieren um einiges einfacher und das Ergebnis sicherer macht.
Danke für die Hinweise, bin gestern abend nicht mehr zum testen gekommen.
Kann ich denn FILE komplett durch FILES ersetzen oder stosse ich dann irgendwo mal auf Probleme ?
Ich habe nämlich gelesen, dass die Methode Paths.toFile (welche ich ja bräuchte um wieder ein FILE-objekt zu erzeugen) nicht unbedingt ein FILE-objekt erzeugt welches Kompatibel zur echten Datei sei.
Würde doch bedeuten, wenn ich jetzt Methoden unter Nutzung der FILE-Klasse schreibe und dann FILES mit einbinde, ich ggf. inkompatible Objekte generiere ?
Also wie wäre der "best practices" ? Nur FILES (oder FILE) benutzen oder ist man sowieso gezwungen beide Klassen zu nutzen ?
wenn du die klassen erstmal richtig schreiben würdest ... nämlich File und Files ... dann könnte man weiter reden ... denn FILE bzw FILES wären konstanten ... > siehe coding conventions
zum topic : File.delete() returned einen bool ... wirft aber keine explizite exception ...
zur SecurityException : wird eigentlich grundlegend von allen I/O-klassen und -methoden geworfen wenn eine aktion nicht zulässig ist ... z.b. in nem Applet oder WebStart-app
und ob man nur File (IO) nutzt ... oder nur Files (NIO.2) ... naja ... ist ne design-entscheidung ... aber man sollte sich für eines entscheiden ...
Ich möchte nur vermeiden jetzt allzuviele Methoden zu schreiben (mit Nutzung von "File") um dann 2 Wochen später festzustellen, dass "Files" besser gewesen wäre.
Habe dann noch dieses Zitat gefunden, welches es vermutlich trifft:
Das macht die »alte« File-Klasse eigentlich überflüssig, aber vermutlich scheut sich Oracle davor, ein @Deprecated an die Klasse zu setzen, denn sonst würden plötzlich riesige Mengen Quellcode in vielen Programmen markiert.
Ich werde also auf "Files" umstellen und mich damit auseinandersetzen.
Ich persönlich würde die neuen NIO Klassen nehmen, falls du Java 7 verwenden darfst.
Sie haben nicht umsonst den ganzen Krempel nochmals geschrieben, anstelle einfach die alte zu verbessern.