Objekte mit Parametern in eine Liste packen

[AbsolutBeginner]

Hi Leute!

Ich bins wieder mit meinen Anfänger-Problemen ...

Also, es gibt eine Class "Item", ein Constructor, der nach einem Namen und einem Preis beim Instanziieren eines Objekts verlangt. Die beiden sollen durch Scanner eingegeben und das neue Objekt der gleichnamigen Liste zugefügt werden. So sieht's dann aus:

Scanner scanner = new Scanner(System.in);
        ArrayList<Item> item = new ArrayList<>();

        while (true) {
            System.out.println("Neue Ware: ");
            String n = scanner.nextLine();
            int p = scanner.nextInt();
            if (n.isEmpty() || p == 0) {
                System.out.println("End of insertion");
                break;
            }
            item.add(new Item(n, p));
        }
        System.out.println(item);
        scanner.close();

Und die exception kriege ich, wenn ich versuche mehr als ein Objekt zu erschaffen:

Neue Ware:
hammer
5
Neue Ware:
colar
Exception in thread "main" java.util.InputMismatchException
    at java.base/java.util.Scanner.throwFor(Scanner.java:939)
    at java.base/java.util.Scanner.next(Scanner.java:1594)
    at java.base/java.util.Scanner.nextInt(Scanner.java:2258)
    at java.base/java.util.Scanner.nextInt(Scanner.java:2212)
    at LearningParts.main(LearningParts.java:13)

Finde aber keinen Fehler in meiner Logik. Könnte mir jemand helfen?

 

[Jw456]

Hallo zeige mal bitte die Kasse Item.

ps nach dem Log sieht es so aus als ob du etwas falsches eingibst .

 

[AbsolutBeginner]

Hallo zeige mal bitte die Kasse Item.

ps nach dem Log sieht es so aus als ob du etwas falsches eingibst .

public class Item {
    private int preis;
    private String name;

    public Item(String name, int preis) {
        this.preis = preis;
        this.name = name;
    }

    public int getPreis() {
        return preis;
    }

    public void setPreis(int preis) {
        this.preis = preis;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "Item [preis=" + preis + ", name=" + name + "]";
    }

}

 

[Jw456]

kann ich mir jetzt auch nicht erkären warum es beim zweiten mal nicht geht.

 

[AbsolutBeginner]

kann ich mir jetzt auch nicht erkären warum es beim zweiten mal nicht geht.

😢 Danke trotzdem 👍

 

[Jw456]

das scanner.nextLine(); wartet doch auf das Enter "CR"
warscheinlich ist das auch im String enthalten. Teste das mal.

 

[temi]

Probier das mal aus:

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        System.out.println(scanner.nextLine());
        System.out.println(scanner.nextInt());
        System.out.println(scanner.nextLine());

    }

Das Problem ist, dass nextInt() nur den Integerwert liest und den darauf folgenden Zeilenumbruch stehen lässt. Das im nächsten Durchlauf folgende nextLine() liest dann sofort diesen Zeilenumbruch, so dass der folgende Eingabeversuch einer neuen Ware eigentlich schon vom nextInt() gelesen wird und das ist kein Integerwert und führt folglich zu einer InputMismatchException.

[CODE lang="java" title="Abhilfe"]String n = scanner.nextLine();
int p = scanner.nextInt();
scanner.nextLine(); // entfernt den "übrig gebliebenen" Zeilenumbruch[/CODE]

 

[AbsolutBeginner]

Probier das mal aus:

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        System.out.println(scanner.nextLine());
        System.out.println(scanner.nextInt());
        System.out.println(scanner.nextLine());

    }

Das Problem ist, dass nextInt() nur den Integerwert liest und den darauf folgenden Zeilenumbruch stehen lässt. Das im nächsten Durchlauf folgende nextLine() liest dann sofort diesen Zeilenumbruch, so dass der folgende Eingabeversuch einer neuen Ware eigentlich schon vom nextInt() gelesen wird und das ist kein Integerwert und führt folglich zu einer InputMismatchException.

[CODE lang="java" title="Abhilfe"]String n = scanner.nextLine();
int p = scanner.nextInt();
scanner.nextLine(); // entfernt den "übrig gebliebenen" Zeilenumbruch[/CODE]

👍 Yep. Ist behoben. Da kommt aber gleich das nächste Problem:

Neue Ware:
Hammer
6
Neue Ware:
Coler
9
Neue Ware:
 
Exception in thread "main"

Die Bedingung "if (n.isEmpty() || p == 0)" n.isEmpty() - wird nicht akzeptiert, die Schleife läuft einfach endlos weiter. Und die 0 muss ich 2 mal nacheinander eingeben, um aus der Schleife rauszukommen.

Liegt es auch an den syntaktischen Besonderheiten von Scanner?

Neue Ware:
Hammer
8
Neue Ware:
colar
1
Neue Ware:
0
0
End of insertion
[Item [preis=8, name=Hammer], Item [preis=1, name=colar]]

So siehts dann korrekt aus, aber nur wenn ich die Abbruchbedingung "0" 2 mal eingebe. Woran liegt es?

 

[kneitzel]

Kannst du den neu erstellten Code zeigen mit der Änderung und den Stacktrace der Exception, die du da scheinbar bekommst mit Zeilenangabe, in welcher Zeile der auftritt?

Und eine Anmerkung: Scanner aus System.in bitte nicht schließen. Damit schließt du auch System.in!

 

[AbsolutBeginner]

Kannst du den neu erstellten Code zeigen mit der Änderung und den Stacktrace der Exception, die du da scheinbar bekommst mit Zeilenangabe, in welcher Zeile der auftritt?

Und eine Anmerkung: Scanner aus System.in bitte nicht schließen. Damit schließt du auch System.in!

import java.util.ArrayList;
import java.util.Scanner;

public class LearningParts {

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        ArrayList<Item> item = new ArrayList<>();

        // System.out.println(scanner.nextLine());
        // System.out.println(scanner.nextInt());
        // System.out.println(scanner.nextLine());

        while (true) {
            System.out.println("Neue Ware: ");
            String n = scanner.nextLine();
            int p = scanner.nextInt(); // Hier war die exception
            scanner.nextLine();  // Und dadurch ist es behoben worden
            if (n.equals("") || p == 0) {
                System.out.println("End of insertion");
                break;
            }
            item.add(new Item(n, p));
        }
        System.out.println(item);
        scanner.close();
    }
}

So. Und das kriege ich, wenn ich versuche, aus der Schleife rauszukommen:

Neue Ware:
hammer
8
Neue Ware:
coler
3
Neue Ware:




Exception in thread "main" // Und das nur, wenn ich manuel die Schleife terminiere

Mit 0 klappt es, aber :

Neue Ware:
hammer
7
Neue Ware:
coler
3
Neue Ware:
0
0
End of insertion
[Item [preis=7, name=hammer], Item [preis=3, name=coler]]

 

[AbsolutBeginner]

Warum wird p == 0 als Abbruchbedingung akzeptiert und n.isEmpty()oder n.equals("") nicht?

Sollte ich lieber mit einem Reader statt mit Scanner probieren?

Also in der Zeile -> int p = scanner.nextInt(); war die InputMismatchException.

 

[kneitzel]

Ok, vermutlich folgendes Problem:
Du gibst bei nextLine das Return ein. Damit ist n der leere String. Dann kommt das nextInt- da drückst Du wieder nur Return.

Er liest so lange ein, bis er ein Token bekommt, also etwas, das kein Leerzeichen, Newline oder so ist.

Nach dem einlesen von p sollte also direkt die Prüfung erfolgen und kein nextInt mehr abgefragt werden.
Somit: zwei if Mut dem break:

 

[AbsolutBeginner]

Ok, vermutlich folgendes Problem:
Du gibst bei nextLine das Return ein. Damit ist n der leere String. Dann kommt das nextInt- da drückst Du wieder nur Return.

Er liest so lange ein, bis er ein Token bekommt, also etwas, das kein Leerzeichen, Newline oder so ist.

Nach dem einlesen von p sollte also direkt die Prüfung erfolgen und kein nextInt mehr abgefragt werden.
Somit: zwei if Mut dem break:

Okay. Die Prüfung erfolgt doch direkt nach int p = scanner.nextInt(); in der ursprünglichen Version. Es soll geprüft werden, ob p ungleich null oder ob der String nicht leer ist. Ich blicke da einfach nicht durch 😞

 

[kneitzel]

Ich blicke da einfach nicht durch 😞

Dann einfach noch etwas mehr Erläuterungen zum Scanner. Das Problem tritt auf, weil Scanner sowohl Token orientiert oder eben Zeilen orientiert arbeiten kann.

Bei Token orientiert gibt es eine Reihe Trennzeichen (Die können auch manuell gesetzt werden wenn man das wollte!) Das sind dann aber per Default erst einmal die sogenannten Whitespace Zeichen (Leerzeichen, Tab, Zeilenumbruch ... - Siehe Character.isWhitespace(Char))

Wenn also ein Token gelesen werden soll, dann geht der Scanner den ganzen Stream durch:
- Er liest so lange Zeichen ein und verwirft diese, bis kein Whitespace kommt.
- Dann liest er non Whitespace Zeichen bis ein Whitespace Zeichen kommt. Die Non Whitespace Zeichen sind dann das Token. Das Whitespace bleibt aber.

Also bei nextInt kann die Eingabe sein: Tab, mehrere Leerzeichen abc leerzeichen Return
==> Tab und Leerzeichen werden gelesen und verworfen. abc wird gelesen als Token. und umgewandelt zu einem int. Das schlägt fehl.
(Danach ist die Eingabe aber noch im Stream!)

Anderer Fall um es deutlich zu machen:
nextInt mit Eingabe: Tab, mehrere Leerzeichen 123 leerzeichen Return
==> Tab und Leerzeichen werden gelesen und verworfen. 123 wird gelesen als Token und umgewandelt zu einem int. Das ist ok, also wird "123" vom Stream entfernt und 123 zurück gegeben.

Noch ein Fall:
Wir haben zwei nextInt hintereinander. Dann können wir eingeben: "123 456\n"
Das erste nextInt liest 123 und gibt es zurück
das zweite nextInt liest direkt die 456 und gibt diese zurück (Der Benutzer muss also nicht noch einmal Return drücken.

Wenn man Zeilenorientiert arbeitet, dann interessiert nur der Zeilenumbruch.
Wenn der schon da ist, muss der Benutzer nichts mehr eingeben. Das war der Fehler der zuerst korrigiert wurde.

==> Merken: Bei Wechsel von Token-basierter Eingabe auf Zeilen Orientierte Eingabe immer ein nextLine aufrufen!

Jetzt beim zweiten Fehler haben wir einfach den Fall, dass der Scanner token basiert was lesen will und so lange liest, bis ein Token gekommen ist. Du kannst also Return drücken so lange Du willst

 

[AbsolutBeginner]

dass der Scanner token basiert was lesen will und so lange liest, bis ein Token gekommen ist

Gut. Die Aufgabe verlang aber, das die 0 und/oder ein leerer String als Abbr.Bedingungen fungieren sollen. Wie implementiere ich das am Besten. Dann vielleicht entweder nur mit einem leeren String oder nur mit einer null?

 

[kneitzel]

Indem Du alles immer direkt prüfst:

        while (true) {
            System.out.println("Neue Ware: ");
            String n = scanner.nextLine();
            if (n.isEmpty()) break;
            int p = scanner.nextInt();
            scanner.nextLine();
            if (p == 0) break;
            item.add(new Item(n, p));
        }
        System.out.println("End of insertion");

Sprich: Wenn schon bei Name nichts eingegeben wurde, dann fragt man nicht erst nach dem Preis.

 

[AbsolutBeginner]

Indem Du alles immer direkt prüfst:

        while (true) {
            System.out.println("Neue Ware: ");
            String n = scanner.nextLine();
            if (n.isEmpty()) break;
            int p = scanner.nextInt();
            scanner.nextLine();
            if (p == 0) break;
            item.add(new Item(n, p));
        }
        System.out.println("End of insertion");

Sprich: Wenn schon bei Name nichts eingegeben wurde, dann fragt man nicht erst nach dem Preis.

Ja. Also mit einem leeren String funktioniert sofort:

Neue Ware:
hammer
6
Neue Ware:
coler
7
Neue Ware:

[Item [preis=6, name=hammer], Item [preis=7, name=coler]]

Mit 0 aber immer noch doppelt:

Neue Ware:
hammer
5
Neue Ware:
coler
7
Neue Ware:
0
0
[Item [preis=5, name=hammer], Item [preis=7, name=coler]]

 

[AbsolutBeginner]

Immerhin, das ist bisher die beste Lösung.

Danke 😊

 

[kneitzel]

Da gibst du ja als Name eine 0 ein. Wenn das auch ein Abbruch Kriterium sein soll, dann musst du das auch Abfragen.

 

[AbsolutBeginner]

Da gibst du ja als Name eine 0 ein. Wenn das auch ein Abbruch Kriterium sein soll, dann musst du das auch Abfragen.

Zugegeben, die Aufgabenstellung an sich ist bisschen ... ungünstig. Im reelen Leben ist es eher so, wie Sie gesagt haben, wenn es keinen Namen gibt, dann brauch man auch keine Preisangaben dazu.

Vielen Dank.