Exception bei Verwendung von LocalDate

[sCream_19]

Servus miteinander!
Ich versuche mich kurz zu fassen. Zur Zeit bearbeite ich eine kleine Hausarbeit, bei welcher ich eine Art kleine Kartei (Freundesliste) programmieren soll. Eines der Attribute, welche der Freund aufweisen soll, ist natürlich sein Geburtstag. Es folgt ein kleiner Auscchnitt aus der Freund-Klasse:

import java.time.LocalDate;

public class Freund {
    
    private String vorName;
    private String nachName;
    private LocalDate geburtsDatum;
    private String telefonNr;
    private String handyNr;
    private String eMail;
    private Adresse adresse;
    
    

    public Freund(String vorname, String nachname, int tag, int monat, int jahr, String strasse, String plz, String ort, String telefonnummer, String handynummer, String email)
    {
        this.vorName = vorname;
        this.nachName = nachname;
        
        LocalDate gDatum = LocalDate.of(jahr, monat, tag);
        this.geburtsDatum = gDatum;
        
        this.adresse = new Adresse(strasse,plz,ort);
        
        this.telefonNr = telefonnummer;
        this.handyNr = handynummer;
        this.eMail = email;
    }
    
    public Freund(String vorname, String nachname, int tag, int monat, int jahr, String strasse, String plz, String ort)
    {
        this(vorname, nachname, tag, monat, jahr, strasse, plz, ort, "","","");
    }

    public Freund(String vorname, String nachname, int tag, int monat, int jahr)
    {
        this(vorname, nachname, tag, monat, jahr, "","","","","","");
    }
    
    public Freund(String vorname, String nachname)
    {
        this(vorname, nachname, 1,1,1950,"","","","","","");
    }

Wenn ich nun in meiner Testklasse ein Objekt der Freund-Klasse erzeuge, läuft alles tadellos, zum Beispiel:

public class FreundTest {

    public static void main(String[] args)
    {
        Freund f2 = new Freund("Herbert", "Hadlich", 07,05,1980, "Marienplatz 23", "97667", "MUC");
        f2.datenAusgeben();           
    }

Die Ausgabe auf der Konsole wäre hierbei:
Name: Herbert Hadlich
Geburtsdatum: 7.5.1980
Adresse: Marienplatz 23, 97667 MUC
Kontakt: Telefonnummer - , Handynummer - , eMail:

Gebe ich zwei speziellle Werte für die Datumsangabe im Konstruktor an, steigt der Compiler aus. Wenn ich "08" oder "09" anstatt "07" als Tag mitgebe, erhalte ich "Exception in thread "main" java.lang.Error: Unresolved compilation problem: The literal 08 of type int is out of range"
Mir ist schon bewusst, dass man Integer-Zahlen nicht mit führender Null schreiben sollte - Ich frage mich gerade nur, wieso die Exception ausschließlich bei diesen beiden Zahlen auftritt.

Kann mir bitte jemand helfen?
MfG

 

[Robat]

Integer, die in Java mit einer 0 beginnen, werden als Zahlen im oktalen System (Basis 8) behandelt. Im Oktalsystem gibt es nur Zeichen von 0 bis 7 .. 8 bzw 9 sind da nicht enthalten, daher meckert der Compiler.

 

[sCream_19]

Was wäre denn die denkbar einfachste Lösung dieses "Problems"? Den übergebenen Parameter im Konstruktor abfragen und gegebenenfalls für mit 0 beginnende Eingaben mit nem if abfangen?

 

[Robat]

Wenn du es, wie jetzt, als Konstante eingibst, ist es ein Compilerfehler .. da brauchst/kannst du zur Laufzeit nichts abfangen weil dein Code gar nicht kompilieren dürfte. Wenn die Eingabe von der Konsole / GUI / ... kommt, kann die Zahl ruhig mit führender 0 eingegeben werden.

 

[sCream_19]

Also ist meine Lösung auf jeden Fall so nicht umsetzbar, nehme ich an

 

[Robat]

Ich versteh nicht wo das Problem liegt. Du wirst ja wohl kaum statisch das Datum da in den Code schreiben wollen, oder?
Erklär vielleicht mal worum genau es dir eigentlich geht

 

[httpdigest]

Falls du die Hinweise/Erklärungen/Gründe, warum dein Programm so nicht kompiliert, nicht verstanden hast, hier das ganze als klare Handlungsanweisung:

Ändere:

Freund f2 = new Freund("Herbert", "Hadlich", 08,05,1980, "Marienplatz 23", "97667", "MUC");

in:

Freund f2 = new Freund("Herbert", "Hadlich", 8,5,1980, "Marienplatz 23", "97667", "MUC");

Fertig.

 

[sCream_19]

@httpdigest - Das hab ich schon verstanden. Mir gehts mehr darum eben abzusichern, dass dieser Fall nicht eintrifft.
@Robat - Naja ich soll nur exemplarisch von einer Containerklasse aus ein paar Objekte anlegen, von daher sollte das auf die Art und Weise reichen denk ich.

 

[httpdigest]

Was meinst du mit: "dass dieser Fall nicht eintrifft"?
Das ist ja, als würde man sagen: "Mir geht es darum, dass Entwickler keinerlei Fehler mehr in ihre Programme einbauen."
Wie ja bereits gesagt, sorgt der Compiler dafür, dass solche Zahlenliterale nicht eingebbar sind. Es handelt sich hierbei wie gesagt um Literale, also Zahlenwerte, die als solche genauso im Code hardgecoded drinstehen.
Das ganze ist kein Problem, wenn es eben keine Literale sind, sondern wenn du z.B. aus einer anderen Variablen einen Zahlenwert ausliest.
Programme, die eben solche Fehler enthalten, sind gar nicht erst übersetzbar/kompilierbar.

 

[mihe7]

Mir gehts mehr darum eben abzusichern, dass dieser Fall nicht eintrifft.

Äh, Du kannst im laufenden Programm nicht absichern, dass der Quelltext korrekt ist. Wenn es um die Exception geht: die kannst Du absichern, indem Du keine halbübersetzten Programme ausführst.

 

[Xyz1]

@sCream_19 Nimm als Parametertyps Strings und setze einen kleinen Parser davor, dann ist Dein Quelltext sozusagen vor unsachgemäßer Verwendung geschützt. Minimale Geschwindigkeitsverringerungen sind denke ich mal hinnehmbar/akzeptabel. Und starte nur Anwendungen die auch vollständig kompilierbar sind.
Später kann ich mir das mal ansehen....

 

[sCream_19]

Danke für den Hinweis Tobias !

 

[Robat]

Nimm als Parametertyps Strings und setze einen kleinen Parser davor,

Sorry aber das ist doch Blödsinn ... Einen ungeeigneten Datentyp nutzen nur weil ein Programmierer kein passendes Literal nutzen kann?

 

[httpdigest]

Warum verwenden wir nicht alle nur noch Strings für alles? Exceptions zur Laufzeit sind doch viiieeel besser als sofortige Compilerfehler zur Übersetzungszeit... NICHT!

 

[sCream_19]

Sorry aber das ist doch Blödsinn ... Einen ungeeigneten Datentyp nutzen nur weil ein Programmierer kein passendes Literal nutzen kann?

Auch wenn ich gerade erst lerne wie man programmiert, so bin ich dennoch selbst fähig genug das passende Literal einzutragen. Ich dachte nur, es gäbe vielleicht in diesem Falle ne Möglichkeit bei ner "08" anstatt ner "8" bei Instanzierung des Objektes dafür zu sorgen, dass die Falscheingabe (für den Fall, dass ich es nicht selbst mache) erkannt und korrigiert wird.

 

[Robat]

@sCream_19 Mir ging es bei dem Beitrag nicht darum dich in irgendeiner Weise als schlechten Programmierer darzustellen. Das du nach Lösungen fragst und die Thematik verstehen willst ist löblich und völlig verständlich.
Mir ging es dabei nur darum die Antwort @Tobias-nrw zu hinterfragen .. Das würde niemand so machen und ist auch völlig unnötig. Du hast ja den Kompiler damit er dir sagen kann, wenn was nicht stimmt. Das mit einem unpassenden Datentyp zu umgehen halte ich für Schwachsinn.

 

[mrBrown]

Ich dachte nur, es gäbe vielleicht in diesem Falle ne Möglichkeit bei ner "08" anstatt ner "8" bei Instanzierung des Objektes dafür zu sorgen, dass die Falscheingabe (für den Fall, dass ich es nicht selbst mache) erkannt und korrigiert wird.

Wie schon mal gesagt: das ist keine falsche "Eingabe", sondern einfach ein Fehler im Code.
Das abfangen zu wollen, ist in etwa so, also würdest du zur Laufzeit abfangen, dass der Programmierer nicht statt einem if ein fi geschrieben hat.

Eingaben zur Laufzeit kannst du mit führenden Nullen tätigen, die werden passend verarbeitet.

Mit einem anderem Java-Compiler würde das ganze bei dir übrigens einen Fehler zur Kompilezeit werfen (der Eclipse-Compiler hat das leider so als Default...)

 

[mrBrown]

Zum Trolle beobachten gehts hier lang: String-Parameter statt Integer

 

[Xyz1]

@mrBrown Dein akk style bezüglich unerwünschten Diskussionen gefällt mir.

 

[mrBrown]

@mrBrown Dein akk style bezüglich unerwünschten Diskussionen gefällt mir.

Danke, glänzen kann ich aber nur dank so wunderbar engagierten wie Dir, die mir immer wieder Gelegenheiten dazu geben <3