+ Antworten
Seite 2 von 5 ErsteErste 1 2 3 4 5 LetzteLetzte
Ergebnis 21 bis 40 von 95

Thema: null-Verteufelung

  1. #21
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.701
    Genannt
    277 Post(s)
    tjaja, Optional und alle funktionalen Spielereien ein möglicher Weg
    Hansa wird Meister

  2. #22
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    167
    Genannt
    19 Post(s)
    NPE ist ein Programmierfehler.
    NPE ist kein Schutz vor etwas sondern eine Kapitulation. Eine Kapitulation der Runtime den geschriebenen Code ausführen zu können.

    Ziel sollte es sein mögliche NPE zur Compilezeit zu entdecken und mit einem Compile Error abzubrechen.

    Leider geht das mit Java so noch nicht und wird vermutlich auch niemals gehen. Es ist halt ein Designfehler in Java der so wohl nie zu beheben ist. Andere Sprachen können das aber.

    Es gibt Tools, die das potentiell entdecken können. Sind aber eben nicht Standard.


    Eine Map muss, eben beim get einen Nullcheck erfordern, bevor etwas mit dem Rückgabewert gemacht wird oder eben den Compiliervorgang abbrechen.
    Oder man ändert die API, dass da ein Optional zurückgegeben wird, dass implizit das weiterarbeiten erlaubt oder einen Nullcheck verlangt oder das explizite übergehen des Nullchecks erfordert.

    Nur "optionale" Variablen dürfen null gesetzt werden, alle anderen müssen ansonsten Initialisiert werden. Optionale Variablen müssen explizit überprüft werden und erst dann verwendet oder eben bedingt weiterverarbeitet werden (z.B. via Optional.map).


    Kurz, wenn Mist gebaut wird soll sich der Compiler melden. NPE ist eine RuntimeException.

  3. Es bedanken sich:
    Timothy_Truckle (17.06.2016)
  4. #23
    User Kilobyte Avatar von Clayn
    Registriert seit
    26.08.2013
    Fachbeiträge
    138
    Genannt
    18 Post(s)
    Wie sieht es denn mit der Compilererkennung im Zusammenhang mit z.b. Spring aus?
    Ich kann mir durchaus vorstellen, dass dort die ein oder andere NPE auftreten wird in der entwicklung weil irgendjemand in irgendner XML Datei an irgendeiner Stelle vergessen hat ein Bean zu definieren
    (Zugegeben ich kenn mich mit Spring nicht so besonders aus [muss allerdings damit rumkämpfen von der Arbeit her] aber afaik werden nicht injizierte Beans nicht angemeckert, wenn keine Annotation benutzt wurde)

  5. #24
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.329
    Genannt
    85 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von Clayn Beitrag anzeigen
    Wie sieht es denn mit der Compilererkennung im Zusammenhang mit z.b. Spring aus?
    Sowas sind Konfigurationsprobleme. Das zählt zu "Fehler können passieren".

    Das Problem das wir hier diskutieren ist: soll man ein NULL zurückgeben?

    bye
    TT

  6. #25
    User Floppy Disc Avatar von Sen-Mithrarin
    Registriert seit
    26.10.2013
    Fachbeiträge
    755
    Genannt
    63 Post(s)
    Ach menno - mal wieder gleich zwei Themen denen ich nur zustimmen kann.

    testen vor release
    Auch wenn ich jetzt nicht gleich in Richtung UnitTest gehe - schlicht weil ich mich damit einfach noch nicht befasst habe - so ist doch ein Grundprinzip klar: Für einen "Rechner" ist jede Codezeile grundsätzlich nur eine mathematische Rechenaufgabe. Und wie wir alle mal in der Schule gelernt haben gibt es für eine mathematische Gleichung nur eine korrekte Lösung. Das bedeutet umgekehrt: Eine bestimmte Abfolge von Sourcecodezeilen kann auch nur ein bestimmtes Endprodukt haben. Kommt am Ende was falsches raus hat der Programmierer einen Fehler gemacht.
    Immer wieder leidiges Beispiel: Minecraft (ja, ich mach auch bei diesem Kindergarten-Hype mit - jedoch dank "extrem"-Modifikationen auf einem sehr hohen und komplexen Niveau)
    Ich geb ja zu: Das was da einige Modder so in ihrer Freizeit leisten ist bemerkenswert - und dafür sollen sie auch ihre Vergütungen aus ihrer Werbung haben. Aber was mich immer wieder teils zur Glut bringt: Einfachste Anfängerfehler und schlicht fehlendes Testen. Warum muss man sich denn auf die Community verlassen dass diese riesige Listen von Bug-Meldungen zusammenträgt - die man dann beim nächsten bugfix-release zum Großteil eh wieder ignoriert wird. Auf Beschwerde-Thread a la "Bekommts mal auf die Kette VORHER selbst zu testen!" reagiert man nur mit perm-ban, Löschung und dem Verweis an die einzelnen Modder zu wenden - wobei die meisten Fehler erst durch das Zusammenfassen als Pack entstehen. Für mich einfach nicht nachvollziehbar.

    Exceptions sind Fehler des Programmieres (zumindest ein Großteil)
    Exceptions - das sagt schon der Name - sind Ausnahmen vom geplanten Programmfluss. Und fast alle sind durch vorherige Prüfungen vermeidbar. Auch ist es ein absolutes no-go Exceptions zur Programmflusssteuerung zu nutzen. Dafür nutzt man sinnvolle return-Werte auf die man dann wiederum prüft.
    Eines meiner Lieblingsbeispiele ist java.io.File:
    FileNotFound - File.exists()
    EndOfFile - File.length()
    Plattenausfall während Lese-/Schreib-Operation - RAID
    Nein, Scherz bei Seite: Natürlich ist ein Head-Crash einer Platte sehr wohl berechtigt eine IOException da es eine nicht vorab prüfbare Ausnahme darstellt. Sicher könnte man hier wirklich so krass in Richtung S.M.A.R.T. und RAID gehen - aber solche hardwarenahen Prüfungen rechtfertigen sich dann vielleicht doch nur bei einem Kernwaffen-Silo.
    Oder auch Sockets: Ein Verbindungsabbruch weil ein Bagger das Cable erwischt hat - dagegrn kann man nun mal nichts machen. Versaut man aber einen sauberen Verbindungsabbau schon in der Protokollspezifikation - naja, eine Steinigung wäre etwas hart - oder bei einigen auch immer noch zu wenig.
    Grob zusammengefasst: Kann ich den Zustand einer Resource vorher und während der Benutzung prüfen und kontrollieren sind Exceptions definitiv ein Fehler vom Programmierer!
    Biskuit ... das is' glaub ich fast so 'ne Suppe
    ein vergruseltes 2016 und so ...
    "Darf ich dir noch was anbieten?" - "Du meinst außer Steaks, Bier, Kippen und nen Lapdance?"

  7. #26
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.701
    Genannt
    277 Post(s)
    NPE ist Programmierfehler, eindeutig, da sollte kein anderer Eindruck entstehen,

    der Clou dabei ist: Programmierfehler kommen so oder so,
    ob null oder alternativ Null-Objekte oder Optional oder sonstiges,

    außer bei Superprogrammierern, da braucht man dann nicht drüber zu reden,
    und na gut, mit super funktionalen Optional-Code sicher auch null-Probleme weitgehend von vornherein ausgeschlossen, dafür nur leider Code unlesbar, kommt für Normalos nicht recht in Frage

    ------

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Eine Map muss, eben beim get einen Nullcheck erfordern, bevor etwas mit dem Rückgabewert gemacht wird oder eben den Compiliervorgang abbrechen.
    Oder man ändert die API, dass da ein Optional zurückgegeben wird, dass implizit das weiterarbeiten erlaubt oder einen Nullcheck verlangt oder das explizite übergehen des Nullchecks erfordert.
    man kann sich solche Wünsch-dir-was-Sprachen ausdenken,
    nur bleiben die zu Recht bis in alle Ewigkeit Nischen ohne Bedeutung,

    Programme müssen in erster Stelle lesbar sein, danach kommen dann die Features,
    andersrum aufgebaut war und wird immer zum Scheitern verurteilt sein

    -----

    Bugs treten also auf in normalen Programmen:
    die Frage ist nur wie diese Fehler sich dann im Programm zeigen,
    entweder direkt in der Programmierung oder die bösestens Bugs durchaus auch erst spät in Produktion
    (heißen Tests bei machen von euch, dass nie nie ein Bug in Produktion passiert? beeindruckend)

    -> ein Bug der mit null zur NullPointerException führt ist deutlich und leicht zu korrigieren,
    danach natürlich keine NullPointerException mehr, wenn idealerweise den Bug repariert,
    ist weder Dauerzustand noch 'Schutz in Produktion', nur schnellste einfachste effektivste Fehleraufdeckung,

    keine Angst vor NPE, sondern immer freuen dass so ideal einen Bug sicher gefunden,
    ganz ohne Bugs wäre Code natürlich noch schöner, aber das ist andere Frage

    -> ein Bug, welcher ohne null mit Null-Objekt, leeren Schleifen auf leere Liste usw. nicht direkt zu NPE führt,
    ist dann umso schwieriger zu finden,
    idealerweise als Sicherheit noch einen Test, der auch ohne Exception anzeigt das was faul ist,
    mit Pech aber Bug noch deutlich länger versteckt
    Geändert von SlaterB (17.06.2016 um 21:27 Uhr)
    Hansa wird Meister

  8. #27
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.329
    Genannt
    85 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von SlaterB Beitrag anzeigen
    heißen Tests bei machen von euch, dass nie nie ein Bug in Produktion passiert? beeindruckend
    Natürlich treten trotz tests auch Fehler in der Produktion auf. Es gibt schließlich genug legacy-Code, der noch nicht mit Unittests abgedeckt ist und da fallen Nebenwirkungen in seltenen Konstellationen naturgemäß auch erst in der Produktion auf, weil diese Spezialfälle bei manuellen Tests üblicher Weise nicht durchlaufen werden, sei es, weil die Zeit nicht reicht oder ganz profan der Tester sie nicht kennt. (das sind ja auch die großen Kritikpunkte am manuellen Testen...)

    Und dann gibt es natürlich immer noch die Bugs, die durch Fehlinterpretation der Anforderungen entstehen, wogegen auch kein Test der Welt hilft...

    bye
    TT

  9. #28
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    167
    Genannt
    19 Post(s)
    Java's Optional ist nicht optimal. Letztendlich sind Lambdas die dort verwendet werden auch nur Callbacks mit all seinen schwierigkeiten und nicht für jeden geeignet.

    Dennoch gibt es Sprachen die es schaffen NPE zu verbannen und Lesbarkeit beizubehalten.

    Beispiel wie Kotlin das löst in Java-Syntax, da dort Variablen Name gefolgt von Typ verwendet wird und dieser auch nicht angegeben werden muss.

    Java Code:
    1.  
    2. // Variablen die null sein können benötigen ein Fragezeichen
    3. String foo = null; // Kompiliert nicht
    4. String foo = "bar"; // OK
    5. String? foo = null; // OK
    6.  
    7. // Kompiliert nicht, weil Rückgabe von null nicht erlaubt
    8. String foo() { return null; }
    9.  
    10. // OK, weil Rückgabe von null erlaubt
    11. String? foo() { return null; }
    12.  
    13. // Kompiliert nicht
    14. Foo? foo = null;
    15. System.out.println(foo.bar);
    16.  
    17. // OK, bar wird nur aufgerufen, wenn foo nicht null ist, also äquivalent mit einem Aufruf von System.out.println(null)
    18. // ?. auch Elvis-Operator genannt.
    19. Foo? foo = null;
    20. System.out.println(foo?.bar);
    21.  
    22. // OK, da foo auf nicht null überprüft wurde.
    23. Foo? foo = null;
    24. if(foo != null) {
    25.   System.out.println(foo.bar);
    26. }
    27.  
    28. // Kompiliert nicht, da foo nicht null sein darf
    29. void f(Foo foo) {}
    30. f(null);
    31.  
    32. // OK
    33. void f(Foo? foo) {}
    34. f(null);
    35.  
    36.  
    37. // OK, führt aber zu einer NPE, !! heißt soviel wie ich "schwöre", dass dies nie null sein kann, ansonsten soll mich der Teufel holen.
    38. void f(Foo foo) {}
    39. Foo? foo = null;
    40. f(foo!!);

    Keine Callbacks, keine Lambdas, nahezu keine Einschränkungen bezüglich der Lesbarkeit.
    Bis auf !! keine Möglichkeit auf NPE. Hinweise bereits beim Kompilieren oder in der IDE.

    Umsetzbar siehe Kotlin, die das bereits tun und damit sogar nach Java 6 compilieren.
    NPE sind auch möglich, wenn Javacode aufgerufen wird der null zurückliefert, aber nicht in Kotlin selbst.

    Es ist also durchaus denkbar, dass es sowas auch in Java geben kann ohne, dass sich jeder gleich beschweren müsste.

  10. Es bedanken sich:
    Crian (21.06.2016), Timothy_Truckle (18.06.2016)
  11. #29
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.910
    Genannt
    309 Post(s)
    Hier hatte jemand names "mariane" geantwortet, der post war "Moderated" und ich hab' mich verklickt (sorry! - ist mir AFAIK noch nie passiert, und passiert hoffentlich nicht wieder), zum Glück war der Inhalt noch im Browsercache:

    Zitat Zitat von mariane
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Das Problem das wir hier diskutieren ist: soll man ein NULL zurückgeben?
    Ja, weil es keine Alternative gibt.
    Eine Methode soll ein passendes Objekt mit dem Attribut x aus einer Liste (kann auch eine Map oder ein Set sein) zurückgeben sofern vorhanden. Dies ist die Vorgabe! Was soll zurückgegeben werden, wenn ein solches Objekt nicht in der Liste existiert?

    Du würdest jetzt also eine Exception werfen und müsstest an allen Stellen die jene Methode aufrufen auf diese Exception hin prüfen. Dies wäre aber ein Missbrauch einer Exception, die nur im Fehlerfall geworfen werden soll und nicht im Fall eines "Nicht gefunden". Dann lieber null zurückgeben und auf null prüfen, das wird auch in der JDK so gehandhabt.

    mariane

  12. #30
    Frequent User Megabyte
    Registriert seit
    01.11.2013
    Fachbeiträge
    1.241
    Genannt
    185 Post(s)
    Blog-Einträge
    1
    Off topic:
    mariane kannte ich noch aus dem JFO, das derzeit massive Probleme zu habn scheint, und ist mit hoher Wahrscheinlichkeit >kein< Troll.


    Ontopic: Deshalb gibt es in Java (bei Collections) immer zwei Methoden, welche null oder Exception zurückgeben, da es in dem Fall von "Element nicht gefunden" nicht definiert ist.
    Näher an den Bits, näher an der Materie
    null-Verteufelung

  13. #31
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.329
    Genannt
    85 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von mariane
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Das Problem das wir hier diskutieren ist: soll man ein NULL zurückgeben?
    Ja, weil es keine Alternative gibt.
    So pauschale Aussagen sind eigentlich immer falsch.

    Zitat Zitat von mariane
    Eine Methode soll ein passendes Objekt mit dem Attribut x aus einer Liste (kann auch eine Map oder ein Set sein) zurückgeben sofern vorhanden. Dies ist die Vorgabe! Was soll zurückgegeben werden, wenn ein solches Objekt nicht in der Liste existiert?
    Es gibt seltene Ausnahmen, in denen NULL tatsächlich valider Teil der Ergebnismenge sein kann (ist mir aber noch nicht unter gekommen). Meist läuft es aber darauf hinaus, dass man das nicht vorhandene Element neu erstellt.


    Zitat Zitat von mariane
    Du würdest jetzt also eine Exception werfen und müsstest an allen Stellen die jene Methode aufrufen auf diese Exception hin prüfen.
    Kann sein, kann auch nicht sein. Wo möglich führt das Fehlen des Objekts dazu, dass ich den gesamten Thread verlassen muss, weil keine sinnvolle Aktion mehr möglich ist. Dann muss ich diese Exception (zusammen mit anderen) nur in der run() Methode des Threads fangen, um dem User eine Fehlermeldung anzuzeigen.


    Zitat Zitat von mariane
    Dies wäre aber ein Missbrauch einer Exception, die nur im Fehlerfall geworfen werden soll und nicht im Fall eines "Nicht gefunden".
    Dass trifft nur dann zu, wenn das Programm im der Fall "Nicht gefunden" genau so weiter arbeitet (arbeiten kann) wie im Fall "gefunden". Wenn das Programm des Fall "Nicht gefunden" irgendwie anders bearbeiten muss ist es durchaus angebracht, das als "Fehler" anzusehen.

    Zitat Zitat von mariane
    Dann lieber null zurückgeben und auf null prüfen,
    Dann ist NULL ein "returned state" was ein noch größeres NOGO ist als die Exception zur Ablaufsteuerung. Außerdem würde jede Aktion, die man dann auf Grund der Information, dass der Rückgabewert ein NULL war, macht, gegen das Prinzip "Tell, don't ask" verstoßen.

    IMHO gibt es also 2 Möglichkeiten damit umzugehen, dass eine Collection ein gesuchtes Element nicht enthält (und NULL kein valider Wert ist):
    1. eine Factory mit geben, die das gewünschte Objekt erzeugen kann,
    2. eine Exception werfen.


    Alles andere ist IMHO nicht mehr OOP.


    Zitat Zitat von mariane
    das wird auch in der JDK so gehandhabt.
    Was nicht automatisch heißt, dass es gut wäre. Auch Java als Sprache hat sich entwickelt und wurde von Menschen geschrieben, die in der Anfangszeit selbst von nicht-OO Sprachen kamen.

  14. #32
    Global Moderator Floppy Disc Avatar von Landei
    Registriert seit
    31.07.2013
    Ort
    Sandersdorf-Brehna
    Fachbeiträge
    991
    Genannt
    164 Post(s)
    Blog-Einträge
    27
    Was bei der ganzen Diskussion klar wird, ist das null keine klare Semantik besitzt, sondern alles mögliche bedeuten kann:
    - Wert ist noch nicht initialisiert
    - Wert kann nicht ermittelt werden
    - Wert ist in dieser Konstellation irrelevant
    - Wert ist in dieser Konstellation prinzipiell nicht sinnvoll
    ...

    Theoretisch gesehen ist der Typ von null eine Unterklasse jeder beliebigen (*) Klasse (so wie Nothing in Scala, nur hat der Typ bezeichnenderweise in Java keinen Namen). Und da liegt auch der Hase im Pfeffer, denn null verhält sich nicht so wie eine Unterklasse - im Gegenteil, null ist die ultimative Verletzung des Liskovschen Substitutionsprinzips, mit allen hässlichen Folgen.

    Sicher, man kann null aus Performance-Gründen, vorgegebener API u.s.w. nicht immer verhindern, aber ich habe die Erfahrung gemacht, dass man es so weit wie möglich vermeiden sollte. Wenn man es einsetzt, dann ganz bewusst, mit klar definierter Semantik, und vor allem möglichst lokal. Ein null-Wert, der durch das System wandert wie eine tickende Zeitbombe, ist fast immer ein Design-Fehler.

    (*) z.B. auch von finalen Klassen, oder Klassen mit privaten Konstruktoren, was schon ein wenig pervers ist, wenn man genauer darüber nachdenkt.

  15. Es bedanken sich:
    Timothy_Truckle (19.12.2016)
  16. #33
    New User Bit
    Registriert seit
    17.12.2016
    Fachbeiträge
    2
    Genannt
    0 Post(s)
    @Timothy_Truckle , danke für deine Ausführung. Ich finde das Thema überaus interessant, da ich mich oft selbst in der Lage sehe: null oder Execption. In dem speziellen Fall, soll tatsächlich nichts passieren, sondern nur dann wenn das Objekt vorhanden ist. Die Option das "fehlendes Objekt" zu erzeugen würde also nicht zutreffen. Bliebe also nur Variante zwei, eine Exception auszulösen, was mich halt ein wenig unbehagt, da es kein wirklicher Fehler ist, ja sogar normal ist, das eine Abfrage keinen Treffer erzielt. In dem Sinne arbeiten auch die Methoden ceiling() oder floor() bei Sets. Ich müsste also auf null prüfen und eine Exception auslösen, an andere Stelle dann reagieren. Bisher prüfe ich genau an dieser Stelle auf null und reagiere.

    mariane

  17. #34
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.701
    Genannt
    277 Post(s)
    zum Thema Suche (etwa in DB) oder Zugriff auf eine Collection (wie Map mit unbekannten Key) ist eine Factory in normalen Sinne natürlich undenbar,
    mit Exception zu reagieren klingt auch für mich, der hier und woanders über Jahre etwas für null kämpft, relativ neu bzw. so unrealistisch, dass vielleicht frühere Erwähungen nicht groß behalten

    die Auflistung
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    IMHO gibt es also 2 Möglichkeiten damit umzugehen, dass eine Collection ein gesuchtes Element nicht enthält (und NULL kein valider Wert ist):

    eine Factory mit geben, die das gewünschte Objekt erzeugen kann,
    eine Exception werfen.
    dürfte da unvollständlich sein,

    naheliegend und recht ernsthafte weitere Alternative, komischerweise von Landei danach nicht direkt angesprochen,
    ist ein Objekt != null, welches Information enthält,
    bei Suchen durchaus bekannt ist etwa eine leere Liste verarbeitbar, und steht für 'nichts gefunden'

    allgemein gibt es das Optional-Konzept, bekannt? ein Link etwa
    Java*8 und java.util.Optional<T>

    für mich kein akzeptabler Kosten-Nutzen-Faktor,
    man müsste quasi das Java-Konzept von Rückgabewert von Methoden aufgeben,
    alles gibt nur noch Optional mit generischen Parameter zurück,

    und wie eine Klasse Person mit String name, String vorname, alle getter mit Optional aussähe?..,

    naja, jedenfalls dritte Alternative und für aufwendige einzelne Klassen wie Map denkbar,
    um mit leeren Ergebnis -> Rückgabe != null, != Exception auszukommen

    -----------

    meiner Ansicht nach ist ein null Programm zwar eine tickende Zeitbombe, aber eine sichtbare,
    deren Explosion mit der vitalen begrüßenswerten NullpointerException sauber beschrieben wird,

    ein Optional, oder gleich tausende von allen möglichen Methoden, die können sich wer weiß wo überall verzetteln, unsichtbare Zeitbomben,
    wenn an einer Position x von 5 Optionals 3 nix drin haben und deren Methoden sich aus zig anderen Optionals zusammensetzen, dann kann man mal schön suchen, wo denn was fehlt,

    es sei denn man hat sehr stringentes Programm, überall ganz exakte Fehlermeldungen wo nichts fehlen darf,
    aber das ist wieder enormer Aufwand, so als würde man jeden Rückgabewert jeder Methode auf null prüfen,
    das macht eben niemand und will auch nicht mit Optional dazu gezwungen werden,

    in normalen Programmen verzichtet man auf hunderte/ tausende Checks, und jedes null wird meist punktgenau als Problem angezeigt, NullPointerException bei Verwendung
    Geändert von SlaterB (18.12.2016 um 21:53 Uhr)
    Hansa wird Meister

  18. #35
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.910
    Genannt
    309 Post(s)
    Ich weiß zwar nicht mehr genau, was ich oben sicher schon dazu geschrieben habe, aber hoffe mal, dass das jetzt nicht zu inkosequent wirkt:

    Ich finde "null" nicht verkehrt, und finde, man sollte es nicht verteufeln. Der Gedanke, eine API zu verwenden, in der jedes mögliche "null" krampfhaft vermieden wurde, indem irgendwelche Optionals oder Exceptions drumgewickelt wurden, klingt grauslig. (Das bezieht sich explizit NICHT auf eine API, bei der es möglich war, sie so "elegant" zu designen, dass "null" nicht nötig war!).

    Sicher, null ist kacke und schlimm, für Leute, die mit Kreide an einer Tafel stehen und was über Typtheorie faseln, aber Teil des täglichen Brotes eines (Java) Programmierers. Wenn man sich genötigt sieht, sowas zu schreiben wie
    Java Code:
    1.  
    2. Value get(Key key) {
    3.     Value value = map.get(key);
    4.     if (value == null) {
    5.         if (map.contains(key)) {
    6.             // Something wrong
    7.         }
    8.     }
    9.     return value;
    10. }
    kann die Zweideutigkeit von "null" schon stören. (Solange wir nicht von 0, NULL und nullptr (<-endlich!) reden müssen, jammern wir da aber auf hohem Niveau).

    Aber Fakt ist: "null" in seiner Zweideutigkeit ist Elementarer Bestandteil der Standard-API, und wird es immer sein. Man kann es also nicht immer sinnvoll vermeiden (und sollte das auch nicht, wenn das heißt, dass man mit Exceptions eine Semantik vermitteln will)

  19. #36
    User Viertel Megabyte Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    364
    Genannt
    31 Post(s)
    Zitat Zitat von Marco13 Beitrag anzeigen
    , aber Teil des täglichen Brotes eines (Java) Programmierers. Wenn man sich genötigt sieht, sowas zu schreiben wie
    Ich bin jetzt etwas spät in diesem Thread eingestiegen, versuche es aber trotzdem:
    Die Idee ist ja nicht, dass Null "böse" ist. Das Problem welches viele mit null haben ist eher, dass man es ignorieren kann. Das kann erwünscht sein, bei kurzen Skripten z.B., aber auch problematisch. Es In Java wurde mal ein Annotationset eingeführt um zu kennzeichnen, dass eine Methode z.B. null zurückgeben kann, aber das hat bei mir im Projekt mal jemand versucht und erfordert auch wieder eine hohe Disziplin und kann trotzdem ignoriert werden. Nullable hilft hier zum einen damit, dass die Möglichkeit eines Null Values ins Interface festgeschrieben wird. Wenn es kein null in der Sprache gibt und ich ändere eine Methode die bisher kein Null zurückgegeben hat dementsprechend ab, dass sie es jetzt tut, fliegen mir Compilerfehler und ich muss mich darum kümmern. Denn genau darum geht es bei dem Gedanken um Optional, dass ich mich darum kümmern muss. Der Entwickler hat keine Chance mehr zu denken "das wird nie null, den Check brauche ich nicht". Und ja, das kann nervig sein, aber ich müsste diese Behandlung ja auch durchführen wenn das Objekt null sein könnte. Ich sehe das in etwa so, wie eine Checked Exception für die NPE, nur dass der Kontrollfluss nicht bricht.

    Die Frage ist nur, ob es Sinn macht Optional Bibliotheken an eine Sprache dranzuflanschen die null als Konzept verwendet. Alle Java APIs und die meisten externen Bibliotheken geben mir null zurück, will ich jetzt wirklich eine zweite Semantik einführen und alle Zugriffe kapseln? Sobald mir nämlich niemand wirklich die Garantie geben kann, dass eine Methode nicht null zurückgeben kann, kann ich mich natürlich auch nicht voll und ganz auf das Konstrukt verlassen.

    Meiner Meinung nach kommt es darauf an, inwiefern man als Entwickler gerne das Tradeoff Freiheit gegen Sicherheit eintauschen möchte. Bei einigen Anwendungsfällen mag ich Typsicherheit, Nullable/Optional und Checked Exceptions, für anderes benutze ich Skriptsprachen ohne statisches Typsystem, die mir Null und andere Runtime Exceptions um die Ohren werfen.
    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.

  20. #37
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.329
    Genannt
    85 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von SlaterB Beitrag anzeigen
    allgemein gibt es das Optional-Konzept, bekannt?
    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 Einführung des Optional (in der umgesetzten Form) war IMHO so unnötig wie ein weiteres Loch im Kopf...

    bye
    TT

  21. #38
    User Viertel Megabyte Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    364
    Genannt
    31 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Die Einführung des Optional (in der umgesetzten Form) war IMHO so unnötig wie ein weiteres Loch im Kopf...
    In Java: Richtig. Weil mich niemand zwingen kann den Check auch wirklich durchzuführen. Hier ist der einzige Mehrwert, wie oben geschrieben, dass die Möglichkeit Null zurückzubekommen in die Methodensignatur aufgenommen wurde.

    Hier könnte ich mir eventuell ein Konstrukt vorstellen das in diese Richtung geht:

    Java Code:
    1. optionalVar.notPresent(
    2.            //doSomething
    3.          ).else(
    4.            //keep on going
    5.          );

    Also eine Buildersyntax, die dir die else Methode erst gibt nachdem du notPresent aufgerufen hast. Aber auch hier kann mal natürlich den Inhalt von notPresent einfach leer lassen...


    Edit: Interessanter Podcast zu der Thematik (wenn auch manchmal nicht so "gradlinig"): https://soundcloud.com/lambda-cast/6-null-and-friends
    Geändert von inv_zim (19.12.2016 um 09:51 Uhr)
    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.

  22. #39
    Global Moderator Floppy Disc Avatar von Landei
    Registriert seit
    31.07.2013
    Ort
    Sandersdorf-Brehna
    Fachbeiträge
    991
    Genannt
    164 Post(s)
    Blog-Einträge
    27
    Was bei der Kritik an Optional oft vergessen wird, ist dass man für die etwas umständlicheren Syntax im Gegenzug etwas (meiner Meinung nach viel wichtigeres) erhält: Komponierbarkeit.

    Angenommen, ein Foo enthält ein "nullbares" Bar, das wiederum ein "nullbares" Baz, und das einen "nullbaren" String. Will ich eine Aktion ausführen oder einen Wert haben, sieht das so aus:

    Java Code:
    1. Foo foo = ...
    2. String s = "unknown";
    3. if (foo.bar() != null) {
    4.   Bar bar = foo.bar();
    5.   if (bar.baz() != null) {
    6.      Baz baz = bar.baz();
    7.      if (baz.string() != null) {
    8.         System.out.println(baz.string()); //Aktion ausführen
    9.         s = baz.string(); //Wert zurückliefern
    10.      }
    11.   }
    12. }

    Wären die Felder stattdessen jeweils Optionals, werden daraus Einzeiler:

    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

    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.

  23. #40
    Frequent User Megabyte
    Registriert seit
    01.08.2013
    Fachbeiträge
    1.722
    Genannt
    111 Post(s)
    Zitat Zitat von inv_zim Beitrag anzeigen
    Hier könnte ich mir eventuell ein Konstrukt vorstellen das in diese Richtung geht
    Das ist doch mit den Optionals möglich. Dafür gibt es die Methoden ifPresent, orElse, orElseGet und orElseThrow. Für die Funktionale Weiterverarbeitung nutzt man filter, map und flatMap. Darin ist dann der isPresent-Check gekapselt.

    *** Edit ***
    @Landei wenn mann dann noch das foo.bar().flatMap(Bar::baz).flatMap(Baz::string) in eine Variable packt, hat man die Methodenkaskade auch nur einmal und das wird noch etwas lesbarer.

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

Direkt antworten Direkt antworten

Schreibe folgende Buchstabenfolge rückwärts: ssenriaF

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
  •