Warum ist der catch-Block nicht erreichbar ?

[lalas]

Hallo,

stehe grad auf dem Schlauch, ich habe diese Methode:

	public String delfile (String filename) {
		
		File temp = new File(filename);
		
		//if (temp.exists() == false) return ("ERROR: File does not exist");
				
		boolean b = temp.exists();
		
		if (b == true) {
	        
			try {
	            temp.delete();
	            return ("File was deleted");
	        }
	        catch (IOException e) {
	            return ("ERROR: "+e);
	        }
	    }
		else return ("ERROR: File not found");

Und Eclipse sagt mir, dass der catch-block nicht erreichbar wäre und somit die exception niemals geworfen würde.
Was übersehe ich hier ?

 

[TKausL]

 temp.delete();

wirft wohl keine IOException.

 

[lalas]

OK, also laut File (Java 2 Platform SE v1.4.2)

wirft es wohl eine exception. Allerdings nur wenn es einen "Security Manager" gibt.

Wirft denn die file-Klasse nicht generell exceptions, z.B. FileNotFound etc. ? Dachte das würde auf die Methoden durchgereicht werden...

EDIT:
Sehe grad es gibt ja auch die FILES klasse, teste es mal damit:
Files (Java Platform SE 7 )

 

[Kevin94]

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.

 

[Camill]

... jedoch Java 7 voraussetzt.

 

[lalas]

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 ?

 

[tröööt]

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 ...

wichtig : NIO.2 Files setzt Java 7 vorraus

 

[lalas]

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:

(von http://openbook.galileocomputing.de/javainsel/javainsel_15_003.html):

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.

Danke für die Meinungen 🙂

 

[Suinos]

Die Klasse Files (Java Platform SE 7 ) selber enthält nur statische Hilfsmethoden, welche alle auf oder mit der neuen Klasse Path (Java Platform SE 7 ) arbeiten.
Deine Entscheidung ist also nicht zwischen

FILE

oder

FILES

, sondern Path (Java Platform SE 7 ) oder File (Java Platform SE 7 ).

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.