+ Antworten
Seite 3 von 5 ErsteErste 1 2 3 4 5 LetzteLetzte
Ergebnis 41 bis 60 von 87

Thema: null-Verteufelung

  1. #41
    User Viertel Megabyte Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    358
    Genannt
    31 Post(s)
    Da bin ich wohl bei weitem nicht mehr auf dem neuesten Stand! Jetzt ist ja Urlaubszeit, da kann ich mich mal wieder aus der "wir sind im Enterprise Umfeld und Java 8 ist noch zu neu" Ecke rausbewegen. Danke für den Hinweis
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

  2. #42
    User Kilobyte
    Registriert seit
    30.07.2008
    Ort
    doubled-town
    Fachbeiträge
    131
    Genannt
    7 Post(s)
    Btw, Kotlin loest das Problem grundsaetzlich:

    Code:
    fun create(...) : Product
    fun find(...) : Product?
    Hier kann nur die find() Methode einen null Wert liefern. Die create() Methode dagegen nicht.

    Benutzt man dann das Ergebnis der find() Methode direkt ohne Sicherheitscheck auf null, gibt es einen Compilefehler.

    Java Code:
    1. Foo foo = ...
    2. foo.bar().flatMap(Bar::baz).flatMap(Baz::string).ifPresent(System.out::println); //Aktion ausführen
    3. String s = foo.bar().flatMap(Bar::baz).flatMap(Baz::string).orElse("unknown"); //Wert zurückliefern

    Das sieht dann im Kotlin so aus:
    Code:
    val nullOrString = foo?.bar?.baz?.toString() // Typ ist: String? (evtl. null)
    val string = foo?.bar?.baz?.toString() ?: "unknown" // Typ ist: String (niemals null)
    Sehr clever gemacht, imho
    "Drohende Diktaturen lassen sich nur bekämpfen, ehe sie die Macht übernommen haben. Es ist eine Angelegenheit des Terminkalenders, nicht des Heroismus." Erich Kästner

  3. #43
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.901
    Genannt
    307 Post(s)
    Zitat Zitat von inv_zim Beitrag anzeigen
    Hier könnte ich mir eventuell ein Konstrukt vorstellen das in diese Richtung geht:
    Wenn Landei nicht geschrieben hätte...

    Zitat Zitat von Landei Beitrag anzeigen
    Wären die Felder stattdessen jeweils Optionals, werden daraus Einzeiler:
    ...
    Sicher, das sieht erst mal ungewohnt aus, aber meiner Meinung nach definitiv besser als die vorherige Variante. Mir scheint, dass vielen hier solche und ähnliche Pattern nicht geläufig sind, und dann muss Optional zwangsläufig wie zusätzlicher Ballast erscheinen.
    ... dann hätte ich das erwähnt: Das kann schon praktisch sein. Aber ich sehe das (und auch die Tatsache, dass das "notwendig" ist!) nicht als Rechtfertigung für "null-Verteufelung". Das sind oft (nicht immer, aber oft) klar definierte und IMHO sinnvolle Konstrukte, auch wenn man sie, wenn man das wollte, bezeichnen könnte als: "Syntaktische Zucker-Workarounds für das böse, böse null".

  4. #44
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Ja, das ist bekannt, aber IMHO ist es kein Unterschied, ob ich
    Java Code:
    1. if(null!=var)
    schreiben muss oder
    Java Code:
    1. if(optionalVar.isPresent())
    die bekannt-Frage ging an mariane, aber jedenfalls schön diese Meinung zu Optional zu lesen

    eine Map mit get(beliebiger Key) sollte also eine Exception werfen?
    gibt immer noch genug Meinungsunterschied..

    --------

    Zitat Zitat von Landei Beitrag anzeigen
    Java Code:
    1. Foo foo = ...
    2. foo.bar().flatMap(Bar::baz).flatMap(Baz::string).ifPresent(System.out::println); //Aktion ausführen
    3. [..]
    alle Aufrufe von Methode baz sollten baz() sein, die Notation ::baz ist eine arg üble,
    allein schon für simple Textsuche über auch auskommentierten Quellcode,

    und fremde Keywörter wie Optional, ifPresent und das völlig verrückte 'flatMap' mitten im normalen Code,
    sowas hat einfach nie eine Chance auf Durchsetzung

    Reflection ist für sich eine Besonderheit, zu Recht auch nur extrem selten eingesetzt,
    normaler Quellcode besteht aus Datentypen, for, if, else, try usw. und den Variablen-, Klassen-, Methodennamen (+ null ),

    wenn eine Suche eine Liste oder ein anwendungsspezifisches Ergebnisobjekt zurückliefert, dann ist das so, und auch OO-sauber,
    aber normaler Quellcode von flatMap() durchsetzt, undenkbar,
    an deinem Beispiel zu sehen stellst du dir das ja anscheinend wirklich für mein Standardbeispiel 'Person mit String name, vorname, alle getter' vor

    ich habe noch kein Programm gesehen was das so verwendet, aber ich sehe freilich auch nicht so viel

    die 3 ifs ineinandergeschachtelt gingen notfalls, selten genug der Fall, kein Beschwerdegrund irgendwo,
    vorzeitiger Abbruch mit return gibt es auch noch
    Geändert von SlaterB (19.12.2016 um 15:35 Uhr)
    Hansa wird Meister

  5. #45
    Global Moderator Floppy Disc Avatar von Landei
    Registriert seit
    31.07.2013
    Ort
    Sandersdorf-Brehna
    Fachbeiträge
    990
    Genannt
    163 Post(s)
    Blog-Einträge
    27
    Zitat Zitat von SlaterB Beitrag anzeigen
    alle Aufrufe von Methode baz sollten baz() sein, die Notation ::baz ist eine arg üble,
    allein schon für simple Textsuche auf über auskommentierten Quellcode,
    Du kannst auch gerne stattdessen x -> x.baz() schreiben. Was an der Notation "übel" sein soll, sehe ich nicht so richtig, ich finde es im Gegenteil gut, dass sich eine Methodenreferenz optisch deutlich von einem normalen Methodenaufruf abhebt. Alles Geschmacks- und vielleicht auch Gewohnheitsfrage (z.B. kommentiere ich Code selten aus, und lösche ihn lieber - wofür gibt es VCSs?). Das erinnert mich alles an die Diskussionen über Generics in Java 5 und vor allen den schrecklichen spitzen Klammern, aber entgegen aller düsteren Prophezeiungen ist das Abendland deshalb nicht untergegangen.

    und fremde Keywörter wie Optional, ifPresent und das völlig verrückte 'flatMap' mitten im normalen Code,
    sowas hat einfach nie eine Chance auf Durchsetzung
    Neue Klassen haben neue Methoden, so what? Was bitte ist an flatMap "unnormal"? Ich bin übrigens ganz froh, dass man es nicht wie in Guava (wo es das seit Jahren gibt) transformAndConcat genannt hat.

    Reflection ist für sich eine Besonderheit, zu Recht auch nur extrem selten eingesetzt,
    normaler Quellcode besteht aus Datentypen, for, if, else, try usw. und den Variablen-, Klassen-, Methodennamen (+ null ),
    Das Codebeispiel enthält keinerlei Reflection.

    die 3 ifs ineinandergeschachtelt gingen notfalls, selten genug der Fall, kein Beschwerdegrund irgendwo,
    Doch, ich beschwere mich, weil ich es furchtbar finde.

    vorzeitiger Abbruch mit return gibt es auch noch
    Ich versuche Methoden mit mehreren returns zu vermeiden, und stehe damit nicht allein da (siehe z.B. Clean Code).
    Geändert von Landei (19.12.2016 um 15:49 Uhr)

  6. #46
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    Zitat Zitat von Landei Beitrag anzeigen
    Das erinnert mich alles an die Diskussionen über Generics in Java 5 und vor allen den schrecklichen spitzen Klammern, aber entgegen aller düsteren Prophezeiungen ist das Abendland deshalb nicht untergegangen.
    abgesehen davon dass ich es nicht so erinnere,
    wie lange hatte es gedauert bis List<String> & Co. in quasi jeder API, jedem Programm, jedem einfachsten Beispiel vorhanden?
    während 'flatMap' bisher quasi genau nirgendwo (alle Seiten, die es zu erklären versuchen und als neu bewerben, ausgenommen)?

    wäre schön einen Zeitrahmen zu haben ab dem das dann ohne Querschüsse Düsterheit, Tellerrand & Co.
    einfach nur objektiv als gescheitert anzusehen erlaubt ist..

    -----------

    Reflection ist für sich eine Besonderheit, zu Recht auch nur extrem selten eingesetzt,
    normaler Quellcode besteht aus Datentypen, for, if, else, try usw. und den Variablen-, Klassen-, Methodennamen (+ null ),
    Das Codebeispiel enthält keinerlei Reflection.
    der Punkt war, dass der Code wie Reflection funktioniert, mit komischen Sonderwörtern, Methoden als Parameter übergeben,
    das ist bei Reflection in einer von 100 Klassen erlaubt, vielleicht noch bei ActionListenern in GUI,
    aber für normalen Code jeder Klasse jeder Methode y.getZ() ein NO GO,

    so darf objektorientierter Code nicht aussehen und so wird er auch nie aussehen in normalen Klassen,
    wenn X von Y ein Attribut Z abfragen will dann heißt das y.getZ(), niemals irgendwas mit flatMap()

    die Kotlin-Syntax kann man ja mal versuchen einzuführen, aber vorher zum Scheitern verurteilt

    ----------

    edit:
    selbst in einem Artikel, der Optional nutzt, für einzelne Sachen wie Suchergebnisse/ Map ja noch vorstellbar
    Java 8: No more loops
    sind die Attribute der Datenklasse Article dort normale Variablen, deren get-Aufrufe null liefern,

    dass irgendwann mal alle Attribute Optional<String> usw. werden sollen, undenkbar
    Geändert von SlaterB (19.12.2016 um 16:25 Uhr)
    Hansa wird Meister

  7. #47
    Frequent User Megabyte
    Registriert seit
    01.11.2013
    Fachbeiträge
    1.233
    Genannt
    185 Post(s)
    Blog-Einträge
    1
    Habe Diskussion nicht vollständig gelesen, habe auch nicht vollständig quergelesen - sondern nur etwa ab der Hälfte. Deswegen verzeiht, wenn ich etwas falsch wiedergebe?

    Wurde contains schon erwähnt?: (und ff.). Da steht auch etwas über null.

    Exception(-handling), Optional und Lambdas schreibe ich an der Stelle nicht - sondern stattdessen immer:

    Java Code:
    1. if (map.get(x) != null) {
    2.  
    3. } else {
    4.  
    5. }

    oder gar:

    Java Code:
    1. if (map.get(x) == null) {
    2.  
    3. } else {
    4.  
    5. }

    Ich hoffe auch, dass das zukünftig nicht aufergezwungenermaßen falsch sein wird.^^

    Das, was Slater schrieb, stimmt selbstverständlich. Im Vergleich zu Generics können sich Lambdas nur schwer/ langsam/ gar nicht durchsetzen - obgleich vielleicht anders beabsichtigt.
    ----
    Verschachtelungstiefe auch noch mal eine neue Frage. Ist 2 noch Ok? Und 3? Wann splitte ich in Methoden? - auch wenn der Zusammenhang dann nicht mehr "schnell" ersichtlich ist?

    Edit: Link:
    https :// docs.oracle.com/javase/7/docs/api/java/util/Map.html#containsKey(java.lang.Object)
    Geändert von CyborgBeta (19.12.2016 um 17:52 Uhr) Grund: Versuch, nachträglich Link einzufügen... (1) Kopierte Links mit ()-Klammern werden nicht mehr umgewandelt (2)
    Näher an den Bits, näher an der Materie
    null-Verteufelung

  8. #48
    User Viertel Megabyte Avatar von mdickie
    Registriert seit
    19.08.2011
    Ort
    Neuland
    Fachbeiträge
    262
    Genannt
    16 Post(s)
    Eine nette Alternative zum contains Aufruf im if wäre
    Java Code:
    1. if ("key" in someMap) {
    2.     System.out.println("Gefunden");
    3. }
    oder nicht null bzw. nicht leer ganz einfach:
    Java Code:
    1.  
    2. if (!someObject) {
    3.    // Objekt normal verwenden
    4. } else {
    5.   // Objekt ist null oder Collection leer
    6. }

    Das wäre meines Erachtens sehr sinnvoller syntaktischer Zucker für Java.
    Eigentum ist böse! Gib' es mir, weil du ja damit nichts damit anfangen kannst. Wenn du Eigentum trotzdem gut findest, dann gefällt dir vielleicht Defective by Design

  9. #49
    User Viertel Megabyte Avatar von mdickie
    Registriert seit
    19.08.2011
    Ort
    Neuland
    Fachbeiträge
    262
    Genannt
    16 Post(s)
    Upps, eigentlich gehört kein Ausrufezeichen beim zweiten Beispiel im if.
    Eigentum ist böse! Gib' es mir, weil du ja damit nichts damit anfangen kannst. Wenn du Eigentum trotzdem gut findest, dann gefällt dir vielleicht Defective by Design

  10. #50
    User Kilobyte
    Registriert seit
    30.07.2008
    Ort
    doubled-town
    Fachbeiträge
    131
    Genannt
    7 Post(s)
    Das Problem ist imho gar nicht so sehr die genaue Syntax (man kann sich auch mit Java6 nette isNull Methoden bauen, die die Checks etwas uebersichtlicher machen). Das Problem ist einfach, dass man niemals sicher sein kann, dass eine Variable/ein Rueckgabewert nicht null ist. D.h. theoretisch muss man JEDEN Zugriff vorher auf Null checken. Dabei ist mir erst mit Kotlin richtig klar geworden, dass da ein Check am Anfang einer Methode nicht unbedingt ausreicht.

    Java Code:
    1.  
    2. class Foo {
    3.    private Bar bar;
    4.    // .. Setter gibts dafuer auch
    5.    public void doit() {
    6.      if( bar==null ) { return;// oder exception }
    7.      bar.doSomething(); // Sicher?
    8.    }
    9. }

    Der Fall oben ist leider nicht sicher, denn die bar Instanzvariable dieser Klasse koennte z.B. von einem andren Thread aus geaendert werden.

    Ich hab ebenfalls lange nicht ganz verstanden, was eigentlich genau das Problem bei einer NPE ist, denn sie zeigt ja genau auf die Stelle, wo eine Variable/Rueckgabewert null ist. Nur leider fehlt dabei voellig, WARUM das so ist. Manchmal ist es voellig offensichtlich, aber spaetestens wenn Threads ins Spiel kommen, kann es u.U. der absolute Horror werden.

    Optional selbst hilft hier auch recht wenig, da eben auch ein Optional prinzipiell null sein koennte.

    Das Schnipsel oben waere uebrigens so korrekter:
    Java Code:
    1.  
    2. public void doit() {
    3.      Bar bar = this.bar;
    4.      if( bar==null ) { return;// oder exception }
    5.      bar.doSomething(); // Sicher?
    6.    }
    "Drohende Diktaturen lassen sich nur bekämpfen, ehe sie die Macht übernommen haben. Es ist eine Angelegenheit des Terminkalenders, nicht des Heroismus." Erich Kästner

  11. #51
    New User Bit
    Registriert seit
    17.12.2016
    Fachbeiträge
    2
    Genannt
    0 Post(s)
    Optional werden ja bisher nur von Streams unterstützt, daheim kann ich damit zwar spielen, aber zu selten besteht wirklich Bedarf, beruflich bin ich auf Java 1.7 derzeit festgenagelt. Lambda & Co sind dennoch schick und werden sich sicher durchsetzen, aber den Umgang damit muss man auch erst lernen - mir fehlt es da noch an Praxis. Allerdings musste ich bei den ersten Gehversuchen feststellen, dass sie nicht unbedingt perfomanter sind.

    Das andere ist, wenn als Rückgabewert kein Optional erwartet wird, muss ich letztlich wieder null zurückgeben, wenn nichts passendes zur Hand ist.

    mariane

  12. #52
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    Zitat Zitat von schalentier Beitrag anzeigen
    Optional selbst hilft hier auch recht wenig, da eben auch ein Optional prinzipiell null sein koennte.
    ganz so schlimm ist es nicht, weil man da schon höhere Prinzipien ansetzen kann,
    Instanzattribute a la final Optional<String> xy = new Optional<>(); sind garantiert != null,

    bei Methoden muss man einfach vertrauen dass diese jeweils richtig programmiert sind, sonst hat man ja gar nix,

    soll man auch Angst haben, dass jede Methode das Programm behindern kann,
    weil theoretisch immer die Möglichkeit besteht, dass böswillig eine Exception geworfen oder System.exit() ausgeführt wird,
    vielleicht mit geheimen internen Timer?

    Methode A und B sind sauber, also auch C welche A und B nutzt, das Prinzip funktioniert schon, alles baut aufeinander auf

    --------

    Zitat Zitat von schalentier Beitrag anzeigen
    Ich hab ebenfalls lange nicht ganz verstanden, was eigentlich genau das Problem bei einer NPE ist, denn sie zeigt ja genau auf die Stelle, wo eine Variable/Rueckgabewert null ist. Nur leider fehlt dabei voellig, WARUM das so ist. Manchmal ist es voellig offensichtlich, aber spaetestens wenn Threads ins Spiel kommen, kann es u.U. der absolute Horror werden.
    die NPE bietet genau soviel, wie technisch auf einfache Weise möglich ist,
    natürlich zaubert sie weder alleine das Programm fertig noch analysiert sie die Fehler zu Ende,
    das kann keine Technik, außer eben superaufwendig Checks und Fehlermeldungen bei jeder Variablen einzeln hingeschrieben
    Geändert von SlaterB (19.12.2016 um 21:30 Uhr)
    Hansa wird Meister

  13. #53
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.901
    Genannt
    307 Post(s)
    @SlaterB und @Landei Übersehe ich gerade was, oder wird die ganze flatMap-Diskussion ad absurdum geführt, dadurch, dass da eigentlich nur map hätte stehen sollen?

    Tatsächlich habe ich gerade mal in einer "aktuellen codebasis" von mir geschaut, und dort tauchte auf...
    Java Code:
    1.  
    2. /**
    3.  * Return the {@link TechniqueParameters} for the uniform with the
    4.  * given name from the given {@link Technique}. If there are no
    5.  * uniforms or parameters in the given {@link Technique}, or the
    6.  * matching parameter is not found, then the optional will be empty.
    7.  *
    8.  * @param technique The {@link Technique}
    9.  * @param uniformName The uniform name
    10.  * @return The optional {@link TechniqueParameters}
    11.  */
    12. private static Optional<TechniqueParameters>
    13.     getOptionalUniformTechniqueParameters(
    14.         Technique technique, String uniformName)
    15. {
    16.     // The technique.uniforms map the uniform names to the
    17.     // technique parameter IDs. The technique.parameters map
    18.     // the technique parameter IDs to the TechniqueParameters.
    19.     Optional<String> techniqueParameterId =
    20.         Optional.ofNullable(technique.getUniforms())
    21.         .map(u -> u.get(uniformName));
    22.     Optional<TechniqueParameters> techniqueParameters =
    23.         Optional.ofNullable(technique.getParameters())
    24.         .flatMap(p -> techniqueParameterId.map(t -> p.get(t)));
    25.     return techniqueParameters;
    26. }

    aaaaaber: Diese Variante war auskommentiert, mit dem statement
    // TODO Really using "Optional" here does not make things better ...

    Und nun steht da wieder
    Java Code:
    1.  
    2.     /**
    3.      * Return the {@link TechniqueParameters} for the uniform with the
    4.      * given name from the given {@link Technique}. If there are no
    5.      * uniforms or parameters in the given {@link Technique}, or the
    6.      * matching parameter is not found, then <code>null</code> is returned.
    7.      *
    8.      * @param technique The {@link Technique}
    9.      * @param uniformName The uniform name
    10.      * @return The {@link TechniqueParameters}
    11.      */
    12.     public static TechniqueParameters
    13.         getOptionalUniformTechniqueParameters(
    14.             Technique technique, String uniformName)
    15.     {
    16.         // The technique.uniforms map the uniform names to the
    17.         // technique parameter IDs. The technique.parameters map
    18.         // the technique parameter IDs to the TechniqueParameters.
    19.         Map<String, String> uniforms = technique.getUniforms();
    20.         if (uniforms == null)
    21.         {
    22.             return null;
    23.         }
    24.         String techniqueParameterId = uniforms.get(uniformName);
    25.         if (techniqueParameterId == null)
    26.         {
    27.             return null;
    28.         }
    29.         Map<String, TechniqueParameters> parameters = technique.getParameters();
    30.         if (parameters == null)
    31.         {
    32.             return null;
    33.         }
    34.         return parameters.get(techniqueParameterId);
    35.     }

    Erstens, weil die verchachtelten Optionals doch (so "schön" sie in anderen Fällen sein könnTen) leicht Gehirnknoten verursachen, und zweitens, weil ... es eigentlich cool wäre, wenn das ganze auch mal auf Android funktionieren würde (aber da gibt's noch andere Punkte, die es raushaut...)

  14. #54
    Global Moderator Floppy Disc Avatar von Landei
    Registriert seit
    31.07.2013
    Ort
    Sandersdorf-Brehna
    Fachbeiträge
    990
    Genannt
    163 Post(s)
    Blog-Einträge
    27
    @Marco13 Sollte sich das nicht vereinfachen lassen zu

    Java Code:
    1. private static Optional<TechniqueParameters> getOptionalUniformTechniqueParameters(Technique technique, String uniformName) {
    2.     return Optional.ofNullable(technique.getParameters()).flatMap(p ->  
    3.            Optional.ofNullable(technique.getUniforms()).map(u ->
    4.                 p.get(u.get(uniformName))));
    5. }

    ?

  15. #55
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    165
    Genannt
    19 Post(s)
    Beim Programmieren gibt es schon seit jeher immer Probleme. Teilweise wurden Sie gelöst.

    Für fehlerhafte Syntax, Compiler und Linter.

    In C über ein Array hinaus schreiben und Lesen ist kein Problem, Java hat eine OutOfBoundsException.

    Speicherverwaltung und Memory-Leaks, Java hat GC.

    Fehlerhaftes Iterieren oder O-Bob, Java bekam foreach und Streams.

    Multithreading wurde mittels Streams auch in einigen Fällen einfacher und sicherer. (Meine Meinung)

    Stackoverflow wegen Rekursion, Scala bekam Tail-Rekursion.

    ClassCastExceptions vor Java 5 durch manuelles Casting, Java bekam Generics. (Ich kenne da auch jemanden, der CCExceptions in Produktivcode gegenüber Generics und deren Schreibweise bevorzugt und mit einem "UUUps, da war ich wohl besoffen" kommentiert)

    Operationen auf Null führen in Java glücklicherweise zu einer NullPointerException, bei anderen Sprachen kann da sonstwas rauskommen, wenn einfach gelesen wird was dort im Speicher zufälligerweise steht.


    Java macht also schon sehr vieles richtig, wenn auch Potential nach oben bleibt. Ein wesentlicher Teil der Probleme wird schon erkannt, wenn das Programm compiliert wird oder bieten sicherer Lösungen an (foreach).
    NPE treten zur Laufzeit auf. Nun gibt es mehrere Herangehensweisen.

    Entweder es juckt mich nicht oder ich behebe es gegebenenfalls, dann hab ich damit kein Problem.
    Ich versuchen Null so gut es geht zu vermeiden.
    Umfangreiche TestSuite und Fuzzy-Testen, so daß potentielle Fehler gefunden werden. Dies macht man auch in den meisten Interpretersprachen (Ruby, PHP, Python, etc. Best Practice um Syntax zu checken, Java hat ja Compiler)
    Alles prinzipiell auf Null überprüfen.

    Wenn man aber alles auf Null überprüft, dann bekommt man auf einen Schlag eine Verdopplung der Komplexität (Branch-Komplexität, Path-Komplexität sieht noch übler aus) im Gegensatz zu einer Welt in der man auf sowas verzichten kann.

    Eine Methode die einen Parameter erwartet, erwartet diesen Parameter! Sie erwartet nicht "Null". Die Methode muss den Parameter überprüfen um sich zu schützen und dann auch noch entscheiden was sie machen soll, sollte doch irgendjemand versuchen ein "Null" unterzuschieben.
    Das ist totaler Wahnsinn!

    Java Code:
    1. public methode(Parameter p) {
    2.   if(p != null) { // Eigenschutz check!, davor lokale Kopie oder synchronisation in Multithreading-Umgebungen siehe Schalentier.
    3.     // eigentliche Arbeit…
    4.   } else {
    5.     // Alternative, Fehlerbehandlung oder alles unter den Tisch fallen lassen?
    6.     // a.
    7.     System.out.println("p darf nicht null sein!");
    8.     // b.
    9.     throw new NullPointerException("p darf nicht null sein!");
    10.     // c.
    11.     throw new IllegalArgumentException("p ungültig!");
    12.     // d.
    13.     // Do nothing.
    14.     // e.
    15.     probiereEsTrotzdem(p);
    16.     // f.
    17.     log.info("p war null, hihi");
    18.   }
    19. }

    Welche dieser 6 Varianten ist denn jetzt genehm?

    Kotlin hingegen als Mustergültiges Beispiel compiliert hingegen einfach kein methode(null);, wenn Parameter erwartet wird. Damit bleibt nur noch die "eigentliche Arbeit" in der Methode. Nullcheck wird beim Aufrufer gemacht, der sich dann auch überlegen kann was er machen könnte, wenn er kein valides Objekt zustande bekommt.

  16. Es bedanken sich:
    cmrudolph (20.12.2016)
  17. #56
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    Zitat Zitat von Landei Beitrag anzeigen
    @Marco13 Sollte sich das nicht vereinfachen lassen zu
    ja was waren das auch bei Generics für Zeiten, als sich alle Experten ebenfalls 'sollte sich das nicht'-Fragen stellten..

    ------
    @Marco13
    der Unterschied zwischen map() und flatMap() hier ergibt sich fast aus der Methodendefinition, sonst z.B.
    Java 8 - Difference between Optional.flatmap and Optional.map - Stack Overflow

    macht die Sache gewiss nicht besser, noch komplizierter und damit fragwürdiger,
    wie du aber ja auch selber schreibst

    ----------
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Nullcheck wird beim Aufrufer gemacht, der sich dann auch überlegen kann was er machen könnte, wenn er kein valides Objekt zustande bekommt.
    es ist eines der wichtigsten Prinzipien überhaupt von Programmierung, etwas in einer Methode zentral zu machen,
    statt hundert Aufrufer es einzeln wiederholen zu lassen,
    bravo zu diesem Rückschritt

    nene, Scherz, wird sicher schon seine Nützlichkeit haben

    gibt es nebenbei auch
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    In C über ein Array hinaus schreiben und Lesen ist kein Problem, Java hat eine OutOfBoundsException.
    ?
    da dann also auch Exception, es muss sich nicht der Verwender des Arrays Gedanken über falschen Index machen oder so?..
    Geändert von SlaterB (19.12.2016 um 22:34 Uhr)
    Hansa wird Meister

  18. #57
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    165
    Genannt
    19 Post(s)
    Schick doch mal ein Leeres Kuvert, mit Absender und korrekt adressiert an das örtliche Finanzamt. Bin gespannt was dann passiert.


    Zitat Zitat von SlaterB Beitrag anzeigen
    es ist eines der wichtigsten Prinzipien überhaupt von Programmierung, etwas in einer Methode zentral zu machen,
    statt hundert Aufrufer es einzeln wiederholen zu lassen,
    bravo zu diesem Rückschritt
    100 Punkte Slater! Völlig richtig. Nicht in hunderten Methoden auf Null überprüfen. Im COMPILER. Das ist die Zentrale Stelle! Nicht die Methode ist das Zentrale Element, der Compiler.

    Der Aufrufer, der ein Problem haben könnte nicht Null zu liefern, ist idR. auch nur Aufgerufener, der das Problem erst bekommt, wenn er nicht sicher sein kann das selbst kein Null untergeschoben wurde.

    Auf ein Null mit einer Exception zu antworten sorgt auch nur dafür, dass der Aufrufer sich wieder darum kümmern muss, was er gerade verbockt hat.

    Java Code:
    1. try {
    2.   methode(null);
    3. } catch (NPE e) {
    4.   // ?!? very funny
    5. }

    IndexOutOfBounds ist zumindest mal ein Fortschritt gegenüber C, wie aber auch erwähnt nicht der Weisheit letzter Schluss.

  19. #58
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.901
    Genannt
    307 Post(s)
    Zitat Zitat von Landei Beitrag anzeigen
    @Marco13 Sollte sich das nicht vereinfachen lassen zu
    ....
    Sicher. Man kann sehr viel in eine Zeile schreiben Aber ich finde es eben gelegentlich besser, Dingen Namen zu geben.

    Man könnte mir vorwerfen, das "zu exzessiv" zu machen. Das geht so weit, dass ich im Prinzip vermeide, mehr als eine Dereferenzierung in einer Zeile zu haben. Also, statt
    Java Code:
    1.  
    2. int nameLength = data.getCustomers(selector.getIndex()).getName().length();
    schreibe ich eben
    Java Code:
    1.  
    2. int index = selector.getIndex();
    3. Customer customer = data.getCustomers(index);
    4. String name = customer.getName();
    5. int nameLength = name.getLength();
    Nicht nur, aber auch (Achtung: ON-Topic ) weil man, wenn bei der ersten Variante eine NullPointerException fliegt, erstmal suchen darf, was denn da gerade null war...

  20. Es bedanken sich:
    Timothy_Truckle (21.12.2016)
  21. #59
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Nicht in hunderten Methoden auf Null überprüfen. Im COMPILER. Das ist die Zentrale Stelle! Nicht die Methode ist das Zentrale Element, der Compiler.
    wenn hundert Methoden vor Aufruf einer Methode X prüfen müssen sind und bleiben es hundert Methoden, statt nur die eine Methode X,

    um NPE wie auch die meisten sonstigen Exceptions muss sich kein Aufrufer direkt kümmern,
    sie fliegen hoch zu zentralen Stellen, allgemeine Fehlerausgabe, Programm- oder Prozessende

    ------

    es gibt Methoden, die mit einem Defaultwert, auch Leerstring, leere Liste oder bestimmte NONE-Enumkonstante oder int-Wert <= 0 klar kommen und andere nicht (so auch Array),
    die nicht-Methoden haben dann auch bei Compiler-null-Schutz genauso Problem, mit dem falschen Wert != null umzugehen,
    und da hilft dann kein Compiler mehr, das Problem läßt sich nicht aus der Welt schaffen
    Hansa wird Meister

  22. #60
    Global Moderator Floppy Disc Avatar von Landei
    Registriert seit
    31.07.2013
    Ort
    Sandersdorf-Brehna
    Fachbeiträge
    990
    Genannt
    163 Post(s)
    Blog-Einträge
    27
    Zitat Zitat von Marco13 Beitrag anzeigen
    Sicher. Man kann sehr viel in eine Zeile schreiben Aber ich finde es eben gelegentlich besser, Dingen Namen zu geben.
    Leider ist das Einführen von Variablen hier kontraproduktiv, weil Java immer noch nicht Typinferenz auf der linken Seite von Initialisierungen erlaubt, wie das z.B. Scala, Kotlin, Swift und C# tun.

    Trotzdem kann (und sollte) man hier auch "ordentliche" Namen vergeben, nämlich an Stelle von p und u. Alternativ kann man aus Lambdas auch Methoden auslagern, eine Möglichkeit wäre z.B.:

    Java Code:
    1.  
    2. private static Optional<TechniqueParameters> getOptionalUniformTechniqueParameters(Technique technique, String uniformName) {
    3.     return Optional.ofNullable(technique.getParameters()).flatMap(parameters ->  parameters.get(methodeMitTollemNamen(technique, uniformName)));
    4. }
    5.  
    6. private static Optional<Uniform> methodeMitTollemNamen(Technique technique, String uniformName) {
    7.    return  Optional.ofNullable(technique.getUniforms()).map(uniforms -> uniforms.get(uniformName));
    8. }

+ Antworten Thema als "gelöst" markieren
Seite 3 von 5 ErsteErste 1 2 3 4 5 LetzteLetzte

Direkt antworten Direkt antworten

In welchem Jahr endete der 2. Weltkrieg?

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Image == null, DrawImage
    Von Quiji im Forum AWT, Swing, JavaFX & SWT
    Antworten: 5
    Letzter Beitrag: 10.06.2015, 09:28
  2. UNIQUE-Index und NULL
    Von SlaterB im Forum Datenbankprogrammierung
    Antworten: 5
    Letzter Beitrag: 05.06.2014, 09:22
  3. Antworten: 12
    Letzter Beitrag: 21.11.2013, 11:15
  4. EntityManager ist immer NULL
    Von mfe_ im Forum Java Enterprise Edition (Java EE)
    Antworten: 4
    Letzter Beitrag: 06.08.2013, 13:28
  5. getBaseLocation() == null?
    Von ???? im Forum DockingFrames
    Antworten: 10
    Letzter Beitrag: 02.09.2010, 04:29

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •