Kürzere Scan Methode

[Hag2bard]

Hallo,
Ich hoffe ich geh euch mit meinen Fragen nicht auf die Nerven.
Manche wirken wahrscheinlich banal.

Ich hab in einem Tutorial von dieser Möglichkeit den Scanner zu benutzen gelesen, welche etwas kürzer im Code ist als das was ich gelernt habe.

Meine Variante :

Scanner scan = new Scanner(System.in);
String name = scan.next();
scan.close

Und die kurze Variante

String name = new Scanner(System.in).next();

Kann man die kurze Variante nehmen?

 

[Wurstkopp]

In der "kurzen" Variante hast du halt keinen Zugriff mehr auf den Scanner wenn du ihn für mehrere/andere aufrufe benötigst. Zudem führst du kein "close()" auf dem Scanner aus.

Das könnte man dann z.B. mit einem AutoClose "try" Block erreichen, aber meine Meinung: Versuch als Anfänger erst mal nicht auf biegen und brechen "Abkürzungen" zu nehmen.

 

[temi]

Zudem führst du kein "close()" auf dem Scanner aus.

Was man sowieso besser nicht machen sollte...

Die "kurze" Variante erzeugt ein "anonymes" Scanner-Objekt, auf dem du danach die Methode next() aufrufst. Anschließend hast du keinen Zugriff mehr auf das Objekt und es wird vom GC irgendwann entfernt. Die erste Variante ist also immer vozuziehen, wenn du mehrfach auf den Scanner zugreifen möchtest. Dann muss die Variable "scan" allerdings auch einen entsprechenden Gültigkeitsbereich haben, z. B. als Instanzvariable.

 

[mihe7]

Meine Variante :

Scanner scan = new Scanner(System.in);
String name = scan.next();
scan.close

Bzgl. des close(): schließe nichts, was Du nicht selbst geöffnet hast. Durch das Schließen des Scanners schließt Du automatisch auch die Standardeinabe, was in der Regel nicht erwünscht ist.

 

[kneitzel]

Bzgl. des close(): schließe nichts, was Du nicht selbst geöffnet hast. Durch das Schließen des Scanners schließt Du automatisch auch die Standardeinabe, was in der Regel nicht erwünscht ist.

Wobei er ja den Scanner selbst erstellt hat und daher ist er für den Scanner und streng genommen für das schließen verantwortlich. Scanner ist nur blöd, da wir ja eben den zugrunde liegenden Stream System.in nicht schließen wollen.

Mein Ratschlag wäre daher immer eine public static final Variante, die einem eine Scanner Instanz gibt um diese dann innerhalb der Text-Oberfläche zu nutzen ...

 

[mihe7]

Scanner ist nur blöd, da wir ja eben den zugrunde liegenden Stream System.in nicht schließen wollen.

Das gilt aber nicht nur für Scanner, sondern z. B auch für BufferedInputSteam 🙂

 

[kneitzel]

Das gilt aber nicht nur für Scanner, sondern z. B auch für BufferedInputSteam 🙂

Naja .. So an Dampf verbrennt man sich nun einmal leicht die Finger ... daher vermeide ich alles, was mit Dampf angetrieben wird 🙂 🙂 🙂 🙂

*SCNR*

Also die Konstellation bei Streams ist normalerweise durchaus so, dass man diese ja nur genau einmal verarbeitet ...

Bei C# fand ich es übrigens immer recht interessant - je nach verwendeter statische Codeanalyse wurde man verhauen, weil man bei so einer "Verschachtelung"
- nicht alles sauber geschlossen hat.
- etwas mehrfach geschlossen wurde.
(also Konstellation B bekommt A und schließt A nun mit. Wenn man nun beides schließt, dann konnte zweites gemeckert werden. Wurde nur B geschlossen, dann konnte A angemeckert werden, weil das nicht explizit geschlossen wurde ...)

 

[mihe7]

Tja, in Java steht halt explizit dabei: "Closing a previously closed stream has no effect." 😛