negative Zahlen bei Intervallen

[Moonchild]

Hallo,
wir sollten ein Programm schreiben, bei dem 2 Zahlen (Untergrenze und Obergrenze) eines Intervalles eingelesen werden. Weiters sollen dann beliebig viele Werte eingelesen werden. Bei 0 ist das Einlesen dann zu Ende. Am Schluss soll ausgegeben werden, wie viele Werte über, zwischen und unter dem Intervall liegen.

Mein Problem: Alles funktioniert bereits. Allerdings wenn ich als Untergrenze eine negative Zahl (zB - 10) angebe und dann Werte wie -12, -15 usw. eingebe, ist die Ausgabe der Anzahl der unter der Untergrenze liegenden Werte falsch. Woran kann das liegen?

import java.util.Scanner;

public class Bsp_3_Intervall {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        
        int untergrenze;
        int obergrenze;
        int zahl;
        int kleiner=0;
        int zwischen=0;
        int groesser=0;
        
        Scanner eing = new Scanner(System.in);
        
        System.out.print("Geben Sie die untere Intervallgrenze ein: ");
        untergrenze = eing.nextInt();
        
        System.out.print("Geben Sie obere Intervallgrenze ein: ");
        obergrenze = eing.nextInt();
        
        System.out.print("Geben Sie eine Zahl ein: ");
        zahl = eing.nextInt();
        
        while (zahl!=0) {
            System.out.print("Geben Sie eine Zahl ein: ");
            zahl = eing.nextInt();
            
            if (zahl<untergrenze) {
                kleiner = kleiner+1;
            } else {
                if (zahl>untergrenze && zahl<obergrenze) {
                    zwischen = zwischen +1;
                } else {
                    groesser = groesser+1;
                }
            }
        }
        eing.close();
        System.out.println("Es liegen " + kleiner + " Zahlen unter, " + zwischen + " Zahlen zwischen und " + groesser + " Zahlen über der Intervallgrenze.");
    }
}

 

[mihe7]

Woran kann das liegen?

Vermutlich daran, dass die in Zeile 24 eingegebene Zahl ignoriert wird. Tatsächlich sind die Zeilen 23-24 überflüssig. Statt einer while-Scheife könntest Du eine do-while-Schleife verwenden.

 

[KonradN]

Du hast drei generelle Probleme die du Untersuchen solltest:

a) was passiert mit ersten Zahl nach der Grenze?
b) was passiert, wenn genau die untere Grenze eingegeben wird?
c) was passiert, wenn die 0 eingegeben wird?

Spiele diesbezüglich deinen Code einmal durch!

 

[temi]

Noch zwei Hinweise am Rande.

Das Schließen des Scanners mit close(), schließt auch den vom Scanner verwendeten InputStream (hier: System.in). Das hat in deinem Fall keine Folgen, weil dein Programm anschließend beendet wird, aber würde dein Programm noch weitergehen, dann könntest du System.in nicht mehr verwenden.

Grundsätzlich sollte man nur Ressourcen schließen, die man auch selbst geöffnet hat und System.in hast du nicht geöffnet.

Variablen sollten erst deklariert werden, wenn sie benötigt werden und nicht als "Deklarationsblock" am Anfang, z. B.:

    public static void main(String[] args) {
     
        Scanner eing = new Scanner(System.in);
       
        System.out.print("Geben Sie die untere Intervallgrenze ein: ");
        int untergrenze = eing.nextInt();
       
        System.out.print("Geben Sie obere Intervallgrenze ein: ");
        int obergrenze = eing.nextInt();
       
        // ...
    }

Das verbessert die Les- und Wartbarkeit des Codes und hilft Fehler zu vermeiden.

 

[Moonchild]

Vermutlich daran, dass die in Zeile 24 eingegebene Zahl ignoriert wird. Tatsächlich sind die Zeilen 23-24 überflüssig. Statt einer while-Scheife könntest Du eine do-while-Schleife verwenden.

Danke! Habe es mit einer do-while probiert und jetzt funktioniert es auch mit negativen Zahlen

 

[KonradN]

Bist du denn alle Punkte mal durchgegangen, die ich genannt habe? Es war halt durchaus etwas mehr zu beheben …

 

[Moonchild]

Noch zwei Hinweise am Rande.

Das Schließen des Scanners mit close(), schließt auch den vom Scanner verwendeten InputStream (hier: System.in). Das hat in deinem Fall keine Folgen, weil dein Programm anschließend beendet wird, aber würde dein Programm noch weitergehen, dann könntest du System.in nicht mehr verwenden.

Grundsätzlich sollte man nur Ressourcen schließen, die man auch selbst geöffnet hat und System.in hast du nicht geöffnet.

Variablen sollten erst deklariert werden, wenn sie benötigt werden und nicht als "Deklarationsblock" am Anfang, z. B.:

    public static void main(String[] args) {
    
        Scanner eing = new Scanner(System.in);
      
        System.out.print("Geben Sie die untere Intervallgrenze ein: ");
        int untergrenze = eing.nextInt();
      
        System.out.print("Geben Sie obere Intervallgrenze ein: ");
        int obergrenze = eing.nextInt();
      
        // ...
    }

Das verbessert die Les- und Wartbarkeit des Codes und hilft Fehler zu vermeiden.

Danke für die Tipps. Den Deklarationsblock bin ich noch so gewohnt vom ersten Semester. Werd ich aber künftig beachten.

Auf das Schließen besteht unser Prof. Deswegen ist es drin

 

[Moonchild]

Bist du denn alle Punkte mal durchgegangen, die ich genannt habe? Es war halt durchaus etwas mehr zu beheben …

Ja, bin ich. Hab es mir angeschaut und auch ausgemerzt. Bei 0 wird abgebrochen, 0 wird nicht mehr mitgezählt. Bei erneuter Eingabe der Grenzzahlen passiert jetzt auch nichts mehr. Diese werden ignoriert

 

[KonradN]

Auf das Schließen besteht unser Prof. Deswegen ist es drin

Also da sind halt zwei Positionen, die aufeinander treffen:
a) Man schließt nichts, das man nicht selbst geöffnet hat. Das führt erfahrungsgemäß zu massiven Problemen.
b) Ein AutoCloseable wird immer geschlossen. Das AutoClosable ist halt ein Interface, das immer geschlossen werden sollte, dafür wurde auch das try with resources eingeführt. (Das wäre dann hier auch zu verwenden, wenn man darauf bestehen würde)

Das Problem kommt jetzt hier nur auf, weil der Scanner ein Problem mit bringt: Er schließt etwas, das ihm übergeben wurde. Das ist aber halt dadurch erklärbar, dass hier einem Pattern gefolgt wird, das bekannt ist von Streams und Readern - die aufeinander erstellt werden und wo das Verhalten ebenso ist. Daher sind so Dinge möglich wie verschachtelte Konstruktoren in nur einem try-with-resources - das äußerste Element wird geschlossen und das schließt alles ...

Die Lösung hier ist aber relativ einfach:

Mach eine statische Variable draus. Die halt eine Lebenszeit der Klasse und daher ist da nichts zu schließen (Die Lebenszeit endet vermutlich nun einmal mit dem Programm):

import java.util.Scanner;

public class Bsp_3_Intervall {

    public final static inputScanner = new Scanner(System.io);
    
    public static void main (String[] args) {
        ...
    }
}

Bezüglich Schreibweise evtl. abklären, was da für Coding Styleguides herschen. Üblich wäre ja bei so Konstanten ein INPUT_SCANNER. Aber hier haben wir eine Instanz mit einem inneren State der sich ständig verändert und daher tendiere ich dazu, es wie eine normale Variable zu behandeln, auch wenn diese static final ist! (Das macht es halt deutlich).

Die Alternative Lösung wäre eine Hilfsklasse, die von InputStream erbst und alles weitergibt an einen InputStream, der dem Konstruktor übergeben wurde. Nur das close() das wird weggelassen. Und dann nutzt man halt im Code ein

try (Scanner scanner = new Scanner(new CloseInterruptingInputScanner(System.io))) {
    // Was auch immer....
}

Generell ist hier aber anzumerken: Die Verwendung von mehreren Scannern auf einem InputStream ist generell nicht angebracht und mit Vorsicht zu nutzen! Hintergrund ist, dass ein Scanner auch Daten puffert.

Etwas Code zur Verdeutlichung:

    @Test
    public void testMultipleScanners() {
        InputStream sourceStream = new ByteArrayInputStream("aaa bbb".getBytes());
        Scanner first = new Scanner(sourceStream);
        Scanner second = new Scanner(sourceStream);

        assertTrue(first.hasNext());
        assertEquals("aaa", second.next());
    }

Wird der Test durchlaufen? Oder was wird passieren? Wir haben nur eine Quelle - den sourceStream. Und aus dem kann man "aaa bbb" lesen.
Wenn man da mit Scanner die Token liest, dann wären das die Token "aaa" und "bbb".

Nun nutzen wir den ersten Scanner und fragen ihn: Gibt es ein Token? Da wir ja 2 Token haben, wird das true zurück geben.
Aber wir haben ja noch nichts gelesen. Daher wäre doch ein "aaa" zu lesen? Das versuchen wir mit dem zweiten Scanner. Aber der wirft eine Exception: NoSuchElementException. Der erste Scanner hat halt bereits den Inhalt des Stream gelesen. Der Stream ist bereits am Ende. Wenn der zweite Scanner versucht zu lesen, dann scheitert es daran.
Der Scanner hat einen internen Buffer und der wurde halt gefüllt. Und man kann sich jetzt überlegen, wie sehr dieser gefüllt wurde. Evtl. liest er ja nur Zeilenbasiert? --> Ist das Verhalten genau dokumentiert? Haben wir einen "Vertrag" der ein spezifisches Verhalten vorgibt? Das ist nicht der Fall. Wir können also ein Verhalten austesten, aber das Ergebnis bringt uns nicht weiter, denn wir wissen nicht, ob es bei allen Implementationen so ist und sein wird! (Und man kann es dennoch ausprobieren. So rein aus Interesse. Wenn ich das ein \n einbaue, dann ändert sich nichts. Es wird weiter komplett eingelesen ...)

Das nur um es etwas zu verdeutlichen. Wenn ich also damit etwas aufbauen wollte, dann wäre das sowas wie ein Singleton Bean/Component/Service .... Die ganze Applikation würde genau einen Scanner für die Eingabe nutzen. (Aber zum Glück ist das rein theoretisch - das wird hoffentlich niemand ernsthaft in eienr großen Anwendung nutzen wollen 🙂 )

 

[temi]

Üblich wäre ja bei so Konstanten ein INPUT_SCANNER. Aber hier haben wir eine Instanz mit einem inneren State der sich ständig verändert und daher tendiere ich dazu, es wie eine normale Variable zu behandeln, auch wenn diese static final ist! (Das macht es halt deutlich).

Konstanten werden üblicher- und sinnvollerweise "final static" deklariert, aber nicht alles was "final static" ist muss deshalb eine Konstante sein. Man könnte jetzt darüber diskutieren, wie man "Konstante" definiert. Vielleicht können Konstanten nur primitive Datentypen sein? Oder Immutable?

Insofern, würde ich es genauso machen wie du beschrieben hast.

EDIT: In den Java Code conventions von Oracle steht als Andeutung dazu:

10.3 Constants Numerical constants (literals) should not be coded directly, except for -1, 0, and 1, which can appear in a for loop as counter values.

Demnach wären Konstanten Literale.

Das ist jetzt alles etwas offtopic. 🙂

 

[Moonchild]

Vermutlich daran, dass die in Zeile 24 eingegebene Zahl ignoriert wird. Tatsächlich sind die Zeilen 23-24 überflüssig. Statt einer while-Scheife könntest Du eine do-while-Schleife verwenden.

Danke für den Tipp. Habe es mit einer do-while gelöst und jetzt funktioniert es auch mit negativen Zahlen