File auf Gültigkeit überprüfen

[y0dA]

Hi!
Also ich bekomme vom Benutzer eine Pfad-String sowie einen Filenamen-String und beide möchte ich überprüfen ob sie gültig sind.

Bsp:

public void isFileValid() throws NoFileException, FileNotFoundException {
		File file = new File(this.fPath + this.fName);
		if (!file.isFile()) {
			throw new NoFileException("blah");
		} else if (!file.exists()) {
			throw new FileNotFoundException("blah");
		} else if (!file.canRead()) {
			throw new CannotReadFileException("blah");
		}
	}

CannotReadFileException und NoFileException sind Spezialisierungen von IOException.

Nun meine Frage, macht das Sinn hier die Exceptions zu werfen oder sollte ich lieber wie folgt fortgehen:

public boolean isFileValid() {
		File file = new File(this.fPath + this.fName);
		return (file.isFile() && file.exists() && file.canRead());
	}

Ich möchte halt das Exception Handling richtig implementieren, nur finde ich die 1. Variante irgendwie komisch.
Weiters habe ich mit Variante 1. auch das "Problem" dass ich nun bis zum Controller hinauf, alle Aufrufer mit "throws" im Methodenkopf schmücken darf.

Jemand Vorschläge?

mfg

 

[maki]

Beides ist möglich, je nachdem.

Sog. "Checked" Exceptions zu deklarieren und vielleciht auch zu werfen machen die Verwendung deiner Methode umständlich, jedesmal einen Try-Catch Block drumherum.

Als Alternative kannst du die isFileValid() Methode nutzen, falls es dann zum Problem kommt kannst du immer noch eine "unchecked" RunTimeException werfen.

 

[y0dA]

Ich könnte die beiden Exceptions (CannotReadFileException und NoFileException) auch von RuntimeException ableiten, jedoch passen jene wohl besser zu IOException?

Wie würdet ihr es handhaben?
Eigentlich ist die Exception-Variante schöner, da ich dann definitiv beim Controller weiß, was vorgefallen ist.

Weiters macht so eine Methode, ohne Rückgabewert eigentlich Sinn bzw was sollte ich hier zurückgeben?

public void isFileValid() throws NoFileException, FileNotFoundException { 
      File file = new File(this.fPath + this.fName); 
      if (!file.isFile()) { 
         throw new NoFileException("blah"); 
      } else if (!file.exists()) { 
         throw new FileNotFoundException("blah"); 
      } else if (!file.canRead()) { 
         throw new CannotReadFileException("blah"); 
      } 
   }

 

[maki]

Was sollte der Controller mit dieser Info anfangen?

Benutze die Standardexception wann immer möglich.
Ich würde nicht zuviele eigene Exceptions definieren, macht die Sache unnötig kompliziert und bringt meistens wenig Vorteile.

FileNotFoundException, IOException etc. ist imho gut genug, kannst du intern in deiner Methode fangen, als "cause" an eine RunTimeException übergeben die du dann wirfst, die kann der Controller auch auswerten und du hast keine checked Exceptions zu fangen.

Wie gesagt, all das im zusammenspiel mit isFileValid.

 

[maki]

public void isFileValid() throws NoFileException, FileNotFoundException {
      File file = new File(this.fPath + this.fName);
      if (!file.isFile()) {
         throw new NoFileException("blah");
      } else if (!file.exists()) {
         throw new FileNotFoundException("blah");
      } else if (!file.canRead()) {
         throw new CannotReadFileException("blah");
      }
   }

Diese Methode sollte imho keine checked Exceptions werfen, sonnst brauchst du sie ja gar nicht, oder?

 

[y0dA]

Also im Grunde genommen ist die Sachlage wie folgt:
Ich habe ein Interface, in welchem folgender Methodenkopf steht:

public void storeTracksFromFile(final String fPath, final String fName, final Class className,
			final Receiver receiver);

Die Implementierung hierzu sieht dann wie folgt aus:

	public void storeTracksFromFile(final String fPath, final String fName, final Class className,
			final Receiver receiver) {
		try {
			FileSystemProcessor fsp = new FileSystemProcessor(fPath, fName);
			if (fsp.isFileValid()) {
				fsp.setItrackParser((ITrackParser) className.newInstance());
				this.storeTracksFromFile(fsp, fPath, fName, receiver);
			} else {
				//FIXME was hier machen??
			}
		} catch (IllegalAccessException e) {
//			FIXME was hier machen??
		} catch (InstantiationException e) {
//			FIXME was hier machen??
		}
	}

Hier stellt sich nun die Frage ob ich die Interface Methode ändern sollte und jener einen boolean Wert statt void als Rückgabewert verpassen sollte?

Ich weiß halt nicht wirklich wie ich hier vorgehen soll, also Exception (checked oder unchecked) werfen oder nur mit boolean arbeiten --> Ziel sollte auf jeden Fall sein, dass der Aufrufer der Interface Methode weiß, ob das speichern geklappt hat oder nicht

 

[maki]

Du musst dich entscheiden:

boolean oder Exception?

Detailierte Fehlermeldungen an den User zu schicken geht am besten mit Exceptions.

Wenn der User nur sehen soll ob es funktioniert hat oder nicht, reicht der boolean als Rückgabewert.
Ansonsten nimmst du Exceptions.

Mit Exceptions musst du dich nochmals entscheiden:
checked oder unchecked?

D.h. immer einen try-catch Block bzw. ein throws im Methodenkopf mit checked Exceptions.
Das macht man wenn man "erwartet" das etwas schief geht, oft der Fall wenn man auf externe Ressourcen wie DBs oder eben das Filesystem zugreift, oft aber nicht immer.
Als Beispiel sei hier die delete Methode der File Klasse genannt, gibt true zurück, wenn die Datei/das Verzeichniss gelöscht wurde, ansonsten false.
Andere Methoden der Fileklasse werfen checked Exceptions.

Mit unchecked Exceptions kannst du signalisieren, dass etwas, das eigentlich nicht schief gehen könnte schief gegangen ist, sehr nützlich wenn es um das aufspüren von Programmierfehlern geht, deswegen sollte man vorsichtig sein mit dem Fangen von RuntimeExceptions.


Mit dem boolean als Rückgabewert brauch man keine "erwarteten", also checked Exceptions zu fangen und spart sich das try-catch bzw. die throws Klausel im Methodenkopf.

 

[y0dA]

Und wofür würdest du dich in diesem konkreten Fall entscheiden, da es sich hier ja auch um FileHandling dreht?

Und wenn ich die Exception Variante benutze, wo soll ich die Exception werfen?

danke schon mal für deine Geduld, mir hier Exceptionhandling näher zu bringen - welches ich bislang leider nur stiefmütterlich benutzt habe.

 

[maki]

In deinem Fall würde ich checked Exceptions verwenden, da du ja sagst:

Also ich bekomme vom Benutzer eine Pfad-String sowie einen Filenamen-String und beide möchte ich überprüfen ob sie gültig sind.

Denn wie wir alle wissen machen Benutzer ständig Fehler

Würde mich allerdings auf die Standard Exceptions beziehen, diese catchen und dann dem Benutzer eine aussagekräftigere Fehlermeldung präsentieren.

 

[y0dA]

Jo danke - dann werde ich die Methode isValid() mit den boolean Werten lassen und dann bei storeTracksFromFile(..) im else Zweig eine IOException werfen.

dankeschön

mfg

 

[maki]

Wozu diese isValid() Methode dann überhaupt?

Könntest ja einfach darauf zugreifen und wenn's kracht wird eine Exception geworfen auf die du entsprechend reagieren kannst, das ist es doch was du möchtest.

 

[y0dA]

Wozu diese isValid() Methode dann überhaupt?

Könntest ja einfach darauf zugreifen und wenn's kracht wird eine Exception geworfen auf die du entsprechend reagieren kannst, das ist es doch was du möchtest.

Jo eh..
Die Methode ist noch ein Relikt aus der Vorzeit dieser Klasse

Ich werde es nun so lösen, dass ich gleich beim Konstruktor des FileSystemProcessor auf Gültigkeit überprüfen - damit weiß ich gleich bei der Instanzierung ob ich ein gültiges Objekt habe.


Also nochmal danke für deine Hilfe.

mfg

 

[maki]

Exceptions solltenimho am besten nicht im Konstruktor geworfen werden, Objekte die einen undefinierten Zustand haben sollten vermieden werden.