Brauche ich while != -1, wenn ich immer einen BufferedReader verwende?

[berserkerdq2]

Hi, bei Inputstreams ist es ja eigentlich so, ich sage while( int c=Inputstream.read() !=-1) etc. Wenn ich aber alles immer in einen BufferedReader mache, kann ich dann alles mit einem String prüfen? Also dann immer mit while(String != null) ?

 

[Robert Zenz]

Theoretisch Ja, praktisch theoretisch Ja.

Es gibt einen Unterschied beim lesen mit einem InputStream und einem BufferedReader. Wenn dein Ziel ist einen ganzen String aus dem Stream zu lesen, also den Stream bis zum Ende zu lesen, dann hilft der BufferedReader nur bedingt weil der Zeilenweise arbeitet, du muesstest also wieder ein char Array lesen wenn der Stream nicht mit einem Zeilenumbruch endet. Wenn du aus einem InputStream Zeilen auslesen willst, dann wird ein BufferedReader funktionieren.

Konkreteres Beispiel wuerde helfen was genau du hier umbauen willst.

 

[berserkerdq2]

Theoretisch Ja, praktisch theoretisch Ja.

Es gibt einen Unterschied beim lesen mit einem InputStream und einem BufferedReader. Wenn dein Ziel ist einen ganzen String aus dem Stream zu lesen, also den Stream bis zum Ende zu lesen, dann hilft der BufferedReader nur bedingt weil der Zeilenweise arbeitet, du muesstest also wieder ein char Array lesen wenn der Stream nicht mit einem Zeilenumbruch endet. Wenn du aus einem InputStream Zeilen auslesen willst, dann wird ein BufferedReader funktionieren.

Konkreteres Beispiel wuerde helfen was genau du hier umbauen willst.

Wollte eigentlich nichts umbauen, habe mir nur gedacht, dass es doch sehr unnötig wäre, dass ich alle auswendig lerne, wenn ich imemr den BufferedReader verwenden kann.

 

[yfons123]

auswendig lernen ist immer doof.. im zweifelsfall endest du bei irgend einem inputstream der von irgendeinem framework kommt der ganz anders ist als der standard input stream

 

[mihe7]

Wollte eigentlich nichts umbauen, habe mir nur gedacht, dass es doch sehr unnötig wäre, dass ich alle auswendig lerne, wenn ich imemr den BufferedReader verwenden kann.

Vier Dinge:

1. Das schöne ist doch, dass Reader und InputStream Basisklassen sind, die das spezifizieren. Diese Spezifikation muss von den davon abgeleiteten Klassen eingehalten werden. Wenn Du mit read() arbeitest, wirst Du also immer -1 am Ende des Streams erhalten, egal ob Du mit einen FileInputStream, FileReader, BufferedReader, ByteArrayInputStream etc. arbeitest.
2. Abgeleitete Klassen können zusätzliche Methoden definieren, die ihrerseits etwas anderes spezifizieren. Das ist bei BufferedReader#readLine() beispielsweise der Fall.
3. Es ergibt sich eigentlich von selbst: das Dateiende wird durch einen Wert dargestellt, der keinen Inhalt darstellen kann. Heißt: ein Wert kleiner 0 (wenn die Methode eine Zahl zurückgibt) oder die null-Referenz (wenn die Methode ein Objekt zurückgibt).
4. InputStream und Reader sind nicht einfach austauschbar. Der InputStream liest Bytes, der Reader dagegen Zeichen.

 

[KonradN]

@mihe7 war schneller ... Also nur noch einmal als wichtige Anregung:
Die Dokumentation wurde nicht ohne Grund geschrieben. Die enthält viele Wichtige Informationen. Daher wirklich mal die Doku von InputSTream und Reader anschauen. Dann versteht man auch die Unterschiede

 

[mihe7]

@mihe7 war schneller ...

Noch nicht richtig wach?

 

[KonradN]

Noch nicht richtig wach?

ja scheint so ... muss ich mir also doch den Kaffee-Vollautomat kaufen, der einem den Kaffee gleich i.V. verabreicht ... dann schlage ich Dich wieder

Edit: Tippen und Denken geht auseinander ... s/Ich/ja

 

[mihe7]

Kaffee-Vollautomat kaufen, der einem den Kaffee gleich i.V. verabreicht

Das sollte ja mit einem Life-Hack leicht erledigt sein