+ Antworten
Seite 1 von 5 1 2 3 4 ... LetzteLetzte
Ergebnis 1 bis 20 von 95

Thema: null-Verteufelung

  1. #1
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.948
    Genannt
    321 Post(s)
    [SlaterB: abgespalten aus https://forum.byte-welt.net/java-for...-schleife.html ]

    Ich versteh' ja diese null-Verteufelung nicht. Es GIBT eben manchmal einen Unterschied zwischen "Nichts" und "Eine leere Liste". Und da nun pauschal Optionals drumzuwickeln kann's auch nicht sein. Es geht doch immer darum, was man modellieren will. Und solange einem "null" keine doppelte Bedeutung zukommt (wie beim Klassiker: "map.get(x)==null" -> 1. x ist nicht vorhanden, 2. x wird auf null gemappt) finde ich, dass ein null auch OK sein kann.

    Off topic:

    Abspaltung dieses Teils der Diskussion in einen eigenen Thread in
    3...
    2...
    1...
    Geändert von SlaterB (16.06.2016 um 22:48 Uhr)

  2. #2
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.330
    Genannt
    86 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von Marco13 Beitrag anzeigen
    Ich versteh' ja diese null-Verteufelung nicht. Es GIBT eben manchmal einen Unterschied zwischen "Nichts" und "Eine leere Liste".
    OK, klär mich auf:
    unter welchen Umständen ist es wichtig, das zu unterscheiden?
    Gib mir bitte ein Beispiel, bei dem sich ein Code grundsätzlich anders verhält abhängig davon, ob die Liste leer ist oder fehlt.
    Tipp: die Schleife nicht abarbeiten zählt nicht.


    Mir ist in 12 Jahren Praxis noch kein Fall untergekommen, bei dem NULL nicht als "Fehlercode" missbraucht wurde.


    bye
    TT

  3. #3
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    jeder Zugriff auf eine Liste (oder beliebiges anderes Objekt) welche/s evtl. nicht gesetzt ist, z.B. in einer Map, in einem Cache,
    oder Suchergebnisse die keine Listen sind

    die Map-Variante mit contains-Abfrage ist etwas ungünstig weil fehleranfällig zweimal Key übergeben
    (fehlerhaft doch mal verschiedene Variablen an den beiden Stellen?,
    und proviziert Code a la if (map.contains(ab.getC().getD()) y = map.get(ab.getC().getD()) )
    und auch unschön oft zweimal in der Map gesucht,

    und in 99% aller optionalen Zugriffe wie bei normalen Attributen hat man nichtmal so eine extra contains-Methode dazu,

    -----

    Optional als Alternative ist eine eigene Art Code, für den man sich entscheiden muss,
    bisschen sehr aufdringlich als Rückgabewert von zig Methoden,
    Methoden verlieren quasi ihre wichtige Eigenschaft des Rückgabewertes,
    werden zum Standardeintopf, der echte Rückgabetyp maximal noch als generischer Parameter beigemischt

    um damit wirklich zu arbeiten, bräuchte es schon extra Sprache mit eigener Syntax für bessere Umsetzung für so etwas grundlegendes,
    wahrscheinlich dann gleich ganz Richtung unsichtbarer getter/ setter, aber das ist ja in Java nicht der übliche Stil

    und Optional bzw. die Leer-Variante darin ist dann nicht analog 'als "Fehlercode" missbraucht'?

    -------

    interessant wäre für mich immer noch, normale Entitäten mit vielen (optionalen) Attributen ohne null umgesetzt zu sehen,
    -> lauter Optional<String> & Co., wenn schon nicht in den Attributen dann zumindest in getter-Methoden?

    an realen Beispielen wie immer Mangelware, so dass ich mal wieder zum fjorum zurückgreifen muss:
    https://github.com/fjorum/fjorum/blo...tity/User.java
    zum Glück bisher nicht Optional-verseucht, viele null-Werte drohen, ganz normal
    Geändert von SlaterB (16.06.2016 um 23:38 Uhr)
    Hansa wird Meister

  4. #4
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.330
    Genannt
    86 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von Marco13 Beitrag anzeigen
    Es GIBT eben manchmal einen Unterschied zwischen "Nichts" und "Eine leere Liste".
    Zitat Zitat von SlaterB Beitrag anzeigen
    jeder Zugriff auf eine Liste (oder beliebiges anderes Objekt) welche/s evtl. nicht gesetzt ist, z.B. in einer Map, in einem Cache,
    oder Suchergebnisse die keine Listen sind
    Das beantwortet die Frage nicht.


    Zitat Zitat von SlaterB Beitrag anzeigen
    Optional als Alternative ist eine eigene Art Code, für den man sich entscheiden muss
    Von Optional war (vom mir) nicht die Rede. Mein Ansatz ist: leere Collection (egal ob Map, Liste oder Set) zurückgeben.

    Optionale Attribute in Objekten, die selbst keine Collections sind sollte durch ein "NullObjekt" des entsprechenden Typs repräsentiert werden. Da kann man dann alle Methoden drauf anwenden und muss nicht wissen, dass es für NULL steht.

    bye
    TT

  5. #5
    Global Moderator Viertel Gigabyte Themenstarter

    Registriert seit
    05.08.2008
    Fachbeiträge
    4.948
    Genannt
    321 Post(s)
    Nun, ich fand das ursprüngliche Beispiel (sei es nun im speziellen auf einer Fehlannahme basierend oder nicht...) ganz passend: Wenn man aus einer Datei, meinetwegen JSON, etwas liest, dann kann das entweder
    Java Code:
    1.  
    2. "someProperty" : null
    oder
    Java Code:
    1.  
    2. "someProperty" : []
    oder
    Java Code:
    1.  
    (nicht vorhanden) sein.

    Aber auch schon bei sehr elementaren Dingen. Irgendeine Baumstruktur
    Java Code:
    1.  
    2. class Node {
    3.     // null for root
    4.     Node getParent() {...}
    5. }
    Da dann ein Optional wäre irgendwie sperrig.

    Wenn ich es grob einordnen solle, würde ich sagen, dass bei Datenstrukturen das "null" schon OK sein kann. Ansonsten müßte man ja schon fast polemisch werden, und fragen, ob man Referenztypen nicht immer und überall durch Optionals ersetzen sollte, weil sie ja immer null sein können (und ob man da dann nicht schlicht die falsche Sprache verwendet). (Abgesehen davon, dass ... *stockt* ... (IST das schon polemisch?) .... naja, ich spreche es einfach mal offen aus: Auch ein Optional kann "null" sein ).

    *** Edit ***

    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    e selbst keine Collections sind sollte durch ein "NullObjekt" des entsprechenden Typs repräsentiert werden. Da kann man dann alle Methoden drauf anwenden und muss nicht wissen, dass es für NULL steht.
    Ja, ich finde dieses "Null-Object-Pattern" auch OK. Gerade bei Collections verwende ich selten bis nie "null", sondern immer "empty...". Aber wenn man auf einer emptyMap eben
    Java Code:
    1.  
    2. String foo = map.get(new Object());
    aufruft, kommt null zurück - und es gibt auch andere Fälle, in denen man mit einem "null" etwas modellieren kann, wofür es kaum ein passendes Null-Object gäbe.

  6. #6
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Zitat Zitat von Marco13 Beitrag anzeigen
    Es GIBT eben manchmal einen Unterschied zwischen "Nichts" und "Eine leere Liste".
    Zitat Zitat von SlaterB Beitrag anzeigen
    jeder Zugriff auf eine Liste (oder beliebiges anderes Objekt) welche/s evtl. nicht gesetzt ist, z.B. in einer Map, in einem Cache,
    oder Suchergebnisse die keine Listen sind
    Das beantwortet die Frage nicht.
    List in Map eben, leere Liste für alles geht nicht, contains-Abfrage fragwürdige Alternative

    oder List als Attribut, welches dünn besetzt nicht überall gesetzt sein soll,
    damit direkt damit zu arbeiten, etwas einzufügen, müsste es ja jeweils eigene aktive Liste sein, nicht Konstante

    --------

    NullObjekte, wie auch List-Konstante, die man mit if abfragt statt auf null abzufragen sind ja dasselbe in grün,
    diese dann nun (im Falle eines ifs) analog 'als "Fehlercode" missbraucht'?

    und bei Nichtabfrage kann es gefährlich werden:
    eine Person liefert Dummy-Parent, dieser wieder Dummy-Parent bis in alle Ewigkeit,
    oder in andere Richtung hundert Schritte durch Objektbaum, obwohl schon bei Schritt 9 längst im Nirvana..

    zudem großer Aufwand der Dummy-Objekte zu jeder Klasse,
    null passt für alles und vermeidet jeden möglichen Fehler, perfekte Lösung

    -------

    mit dem Zusatz der für mich noch dazukommt: wieso nur wird eine NullPointerException verteufelt?
    ist für mich ein idealer Fehler (wenn schon Fehler..), zeigt immer haargenau die Stelle an in der etwas schief läuft,

    bloß nicht das null umgehen und in 3 Dummy-Objekten entfernt über unbekannten Zustand wundern
    oder in 3 else entfernt in ganz anderen Code landen als angenommenen Verlauf und zurückzuverfolgen,
    wo genau falsch abgebogen wurde

    in Produktion freilich NullPointerException oft dramatischer ,
    aber so oder so Problem wenn X angenommen und Y unerwartet passiert,

    Abbruch mit Fehlermeldung eh nötig,
    für alle Fälle in denen man eine bestimme Meldung eingeplant hat, kommt die auch,
    für alle restlichen unbedachten Fällen die NullPointerException,
    evtl. zur Sicherheit vorher eine Info-Meldung für den aktuellen Subprozess hinterlegt,

    umrandet mit sauberer Fehlerausgabe (bestimmte Meldung oder 'allgemeiner Fehler aufgetreten')
    + genauen internen Log + Kontrolle über alle Ressourcen kann nicht viel passieren
    Geändert von SlaterB (17.06.2016 um 00:29 Uhr)
    Hansa wird Meister

  7. #7
    Global Moderator Floppy Disc
    Registriert seit
    30.07.2013
    Fachbeiträge
    846
    Genannt
    112 Post(s)
    Zitat Zitat von SlaterB Beitrag anzeigen
    NullObjekte, wie auch List-Konstante, die man mit if abfragt statt auf null abzufragen sind ja dasselbe in grün,
    diese dann nun (im Falle eines ifs) analog 'als "Fehlercode" missbraucht'?
    Nee, man kann in einer Schleife "durch eine leere Liste laufen" ohne einen Fehler wie eine NPE um die Ohren gehauen zu bekommen.

    Zitat Zitat von SlaterB Beitrag anzeigen
    mit dem Zusatz der für mich noch dazukommt: wieso nur wird eine NullPointerException verteufelt?
    ist für mich ein idealer Fehler (wenn schon Fehler..), zeigt immer haargenau die Stelle an in der etwas schief läuft,
    Eine NPE ist in 99% ein Programmierfehler: Eine fehlende Null abfrage zB.
    Wenn man das nur irgendwie vermeiden koennte.. ach ja, s.o.
    Maven is never completely installed

  8. Es bedanken sich:
    Landei (17.06.2016), Sym (17.06.2016), Timothy_Truckle (17.06.2016)
  9. #8
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    Zitat Zitat von maki Beitrag anzeigen
    Nee, man kann in einer Schleife "durch eine leere Liste laufen" ohne einen Fehler wie eine NPE um die Ohren gehauen zu bekommen.
    also nicht im genannten '(im Falle eines ifs)'

    Zitat Zitat von maki Beitrag anzeigen
    Eine NPE ist in 99% ein Programmierfehler: Eine fehlende Null abfrage zB.
    Wenn man das nur irgendwie vermeiden koennte.. ach ja, s.o.
    wenn man an dieser Stelle keine fehlende/ leere Liste zu durchlaufen erwartet
    ist es mit NullPointerException wie leerer Schleife derselbe fachliche Fehler,

    mit einer NullPointerException wird man bestens drauf hingewiesen,

    mit einer leeren Schleife dagegen erfährt man nichts davon und hält womöglich alles für in Ordnung..,
    etwa falls keine zwingende Aktion erfolgen muss,
    anderenfalls muss man auch erst vom Fehlen der Aktion zurückverfolgen, woran es denn lag,
    wo hat die Aktion nicht stattgefunden, beim Durchlauf der Liste X, oder war schon dessen Owner-Objekt nicht vorhanden oder davor..

    ------

    schau dir den Code der Welt an, allein schon
    Java Code:
    1. System.out.println("Trying three lists with the guarded enhanced for loop:\n");
    niemand schreibt vor jeder solchen Zeile 'Eine fehlende Null abfrage' a la if (System.out == null) und was sollte man auch im else-Fall tun?

    ein null-Objekt dort das nichts macht und einem später ratlos lässt warum keine Ausgabe erfolgt,
    oder eine Optional-Variante mit orElse() wäre unsinnig,

    es ist die einfache und sinnvollste Variante: entweder es funktioniert wie angegeben oder es gibt eine NullPointerException mit dem wichtigen direkten Hinweis, dass an dieser Stelle System.out nicht gesetzt ist
    -> alle Infos vorhanden den Fehler zu suchen

    Alternative höchstens die Vorstellung eines Programms, das verhindert je null überhaupt zu setzen
    (und dann auch alle verwendeten Frameworks usw., in Java unrealistisch)
    Geändert von SlaterB (17.06.2016 um 06:56 Uhr)
    Hansa wird Meister

  10. #9
    Global Moderator Floppy Disc
    Registriert seit
    30.07.2013
    Fachbeiträge
    846
    Genannt
    112 Post(s)
    oft ist eine leere Menge kein Fehler, sondern eben nur sehr schnell abzuarbeiten

    Java Code:
    1. menge != null
    kann in den Fallen in denen eine leere Menge einen Fehlerfall darstellt durch
    Java Code:
    1. !menge.isEmtpy()
    ersetzt werden, etwas das mit null Pruefung sonst durch
    Java Code:
    1. menge != null && !menge.isEmtpy()
    zu ersetzen, also selbst in diesen Faellen ist null nicht so gut

    Der einzige Fall der mir in den Sinn kommt wenn ein NullObjekt nicht so dolle ist, ist wenn menge mutable sein soll.
    Geändert von maki (17.06.2016 um 07:21 Uhr)
    Maven is never completely installed

  11. Es bedanken sich:
    Sym (17.06.2016), Timothy_Truckle (17.06.2016)
  12. #10
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.330
    Genannt
    86 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von SlaterB Beitrag anzeigen
    mit einer leeren Schleife dagegen erfährt man nichts davon und hält womöglich alles für in Ordnung..,
    wenn eine leere Liste ein Fachlicher Fehler ist, warum soll der dan durch ein NULL statt einer Exception kommuniziert werden?


    Zitat Zitat von SlaterB Beitrag anzeigen
    und hält womöglich alles für in Ordnung..,
    etwa falls keine zwingende Aktion erfolgen muss,
    Wenn "keine zwingende Aktion erfolgen muss" ist das iterieren über eine leere Liste (was ja eben keine Aktion aus löst) doch voll in Ordnung. Welchen Mehrwert für das Programm bringt es, wenn ich hier auf NULL Prüfen muss, obwohl NULL und "leer" im Prinzip gleich zu behandeln sind (->keine Aktion)?


    Zitat Zitat von SlaterB Beitrag anzeigen
    und einem später ratlos lässt warum keine Ausgabe erfolgt
    jane, isklar:
    Ist natürlich ein gewaltiger Unterschied, ob ich einfach "Größe der Liste: "+liste.size() ins Log schreibe oder im if "keine Liste bekommen"...
    Und wenn die leere Liste ein fachlicher Fehler ist, warum wirft dann der Ersteller der Liste nicht schon eine Exception, wenn er nichts zum reinpacken hat, anstatt NULL zurückzuliefern?


    Zitat Zitat von SlaterB Beitrag anzeigen
    Alternative höchstens die Vorstellung eines Programms, das verhindert je null überhaupt zu setzen
    (und dann auch alle verwendeten Frameworks usw., in Java unrealistisch)
    Also wenigstens kann man auf der JVM bleiben: Ceylon: Welcome to Ceylon

    Zitat Zitat von SlaterB Beitrag anzeigen
    schau dir den Code der Welt an, allein schon
    Java Code:
    1. System.out.println("Trying three lists with the guarded enhanced for loop:\n");
    niemand schreibt vor jeder solchen Zeile 'Eine fehlende Null abfrage' a la if (System.out == null) und was sollte man auch im else-Fall tun?
    Wenn Du schon mit "freier Wildbahn" argumentierst:
    Wie oft ist den bei Dir genau diese Anweisung mit 'ner NPE ausgestiegen?

    bye
    TT
    Geändert von Timothy_Truckle (17.06.2016 um 08:34 Uhr)

  13. #11
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Zitat Zitat von SlaterB Beitrag anzeigen
    mit einer leeren Schleife dagegen erfährt man nichts davon und hält womöglich alles für in Ordnung..,
    wenn eine leere Liste ein Fachlicher Fehler ist, warum soll der dan durch ein NULL statt einer Exception kommuniziert werden?
    wieso 'statt'?
    das null garantiert die nötige Exception während mit einer leeren Liste womöglich gar nichts passiert,
    das ist das Problem: durch Verzicht auf null keine Exception wo eine Exception kommen soll!

    wenn man immer fehlerfrei programmiert und das if (schlechte Situation) throw passende Exception IMMER da hat, dann braucht es keine Absicherung,
    aber Fehler/ Vergessen passieren jeden Tag, und null + NullPointerException ist der natürliche vorhandene Schutz

    spätes edit: mal ganz abgesehen davon, wie ohne null und Optional zwischen 'nicht initialisiert' und reguläres Ergebnis leere Liste unterschieden werden sollte,
    ich nehme an new ArrayList() vs. Konstante EMPTY_LIST ?
    Sym im nächsten Posting erinnert wieder an diesen zentralen Punkt

    -----

    Wenn "keine zwingende Aktion erfolgen muss" ist das iterieren über eine leere Liste (was ja eben keine Aktion aus löst) doch voll in Ordnung. Welchen Mehrwert für das Programm bringt es, wenn ich hier auf NULL Prüfen muss, obwohl NULL und "leer" im Prinzip gleich zu behandeln sind (->keine Aktion)?
    wenn eine initialisierte Liste, ein gesetzes Attribut/ Suchergebnis durchlaufen werden soll, nicht-initialisierte Liste einen Fehler darstellt,
    dann merkt man es bei null sofort,
    während man mit einer leeren Liste nicht merkt dass etwas fehlt

    Und wenn die leere Liste ein fachlicher Fehler ist, warum wirft dann der Ersteller der Liste nicht schon eine Exception, wenn er nichts zum reinpacken hat, anstatt NULL zurückzuliefern?
    eher die null-Liste, während eine leere Liste ja auch ein normales Ergebnis sein kann,
    aber allgemein hinsichtlich allen 'warum macht jemand vorher nicht xy?':
    wie gesagt: in einem perfekten Programm ohne alle Bugs, ohne je eine vergessene nötige Code-Zeile, braucht man sich keine Sorgen machen,

    wenn es aber aus irgendeinem Grund im Programmablauf (und sei es exotisches wie Mehrthread-volatile-Fehler) an erster Stelle durchkommt,
    dann ist mit null zumindest die Entdeckung bei der nächsten Verwendung garantiert,
    während mit Vermeidungs-Objekten der Bug eben auch in weiteren Schritten potentiell verschleiert wird, objektiv schlechter

    Wenn Du schon mit "freier Wildbahn" argumentierst:
    Wie oft ist den bei Dir genau diese Anweisung mit 'ner NPE ausgestiegen?
    noch nie
    Geändert von SlaterB (17.06.2016 um 12:01 Uhr)
    Hansa wird Meister

  14. #12
    Projekt-Moderator Butterfaces Halbes Megabyte Avatar von Sym
    Registriert seit
    31.07.2013
    Fachbeiträge
    576
    Genannt
    28 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    OK, klär mich auf:
    unter welchen Umständen ist es wichtig, das zu unterscheiden?
    Gib mir bitte ein Beispiel, bei dem sich ein Code grundsätzlich anders verhält abhängig davon, ob die Liste leer ist oder fehlt.
    Tipp: die Schleife nicht abarbeiten zählt nicht.
    Es kann bedeuten, dass in einem Fall die Liste (z.B. der wählbaren Standorte) noch nicht initialisiert ist und im anderen Fall eben fachlich keine Standorte existieren.

    Ich unterscheide häufiger zwischen leerer und null-Liste.

    edit: ich hätte wohl die anderen Antworten vorher lesen sollen. Naja.
    Geändert von SlaterB (17.06.2016 um 11:57 Uhr) Grund: Tippfehler
    www.butterfaces.org = JSF 2 + Bootstrap + JQuery = awesome
    https://github.com/larmic

  15. #13
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.330
    Genannt
    86 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von SlaterB Beitrag anzeigen
    wieso 'statt'?
    das null garantiert die nötige Exception während mit einer leeren Liste womöglich gar nichts passiert,
    das ist das Problem: durch Verzicht auf null keine Exception wo eine Exception kommen soll!
    Irgendwer muss statt der leeren Liste ein NULL zurückgeben, wenn Du beim Zugriff auf die Liste eine NPE haben willst.
    Warum kann dieser jemand nicht selbst eine (aussagekräftige) Exception werfen, anstatt NULL zurückzuliefern?


    Zitat Zitat von SlaterB Beitrag anzeigen
    wenn man immer fehlerfrei programmiert und das if (schlechte Situation) throw passende Exception IMMER da hat, dann braucht es keine Absicherung,
    Dann mach es doch so.


    Zitat Zitat von SlaterB Beitrag anzeigen
    aber Fehler/ Vergessen passieren jeden Tag, und null + NullPointerException ist der natürliche vorhandene Schutz
    Das ist kein Schutz, sondern ein Problem.
    Es kann passieren, weil man halt mal Fehler macht, ja. Aber es darf nicht beabsichtigtes Verhalten sein!


    Zitat Zitat von SlaterB Beitrag anzeigen
    spätes edit: mal ganz abgesehen davon, wie ohne null und Optional zwischen 'nicht initialisiert' und reguläres Ergebnis leere Liste unterschieden werden sollte,
    Die Frage ist, WARUM sollte das unterschieden werden? Bisher habe ich darauf keine Antwort...


    Zitat Zitat von SlaterB Beitrag anzeigen
    wie gesagt: in einem perfekten Programm ohne alle Bugs, ohne je eine vergessene nötige Code-Zeile, braucht man sich keine Sorgen machen,
    Warum willst Du es dann absichtlich mit NPEs durchsetzten?
    Das "Vergessen einer nötigen Code-Zeile" bekommt man viel besser zur Programmierzeit mit Unittests in den Griff. Da braucht man keine NPEs zur Laufzeit.


    Zitat Zitat von SlaterB Beitrag anzeigen
    dann ist mit null zumindest die Entdeckung bei der nächsten Verwendung garantiert,
    Nochmal: Gib mir ein valides Beispiel, wo der Unterschied, ob eine Collection leer oder NULL ist ein anderes Verhalten bedeutet, und diese Situation nicht bereits vom Ersteller der Liste erkannt (und per Exception kommuniziert) werden könnte.


    Zitat Zitat von Sym Beitrag anzeigen
    Es kann bedeuten, dass in einem Fall die Liste (z.B. der wählbaren Standorte) noch nicht initialisiert ist und im anderen Fall eben fachlich keine Standorte existieren.
    Mit anderen Worten, Du hast in Deinem Programm keinen dedizierten Initialisierungsprozess. Auch da ist die NULL-Liste ein Symptom für ein Problem.

    Zugegeben, es gibt Probleme, deren Lösung unverhältnismäßig wäre...

    bye
    TT

  16. #14
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Irgendwer muss statt der leeren Liste ein NULL zurückgeben, wenn Du beim Zugriff auf die Liste eine NPE haben willst.
    Warum kann dieser jemand nicht selbst eine (aussagekräftige) Exception werfen, anstatt NULL zurückzuliefern?

    ..

    Das ist kein Schutz, sondern ein Problem.
    Es kann passieren, weil man halt mal Fehler macht, ja. Aber es darf nicht beabsichtigtes Verhalten sein!

    ..

    Das "Vergessen einer nötigen Code-Zeile" bekommt man viel besser zur Programmierzeit mit Unittests in den Griff. Da braucht man keine NPEs zur Laufzeit.
    als Dauerzustand ist die NullPointerException nicht gedacht, nur zum Finden des Bugs mit dann Korrektur,
    Korrektur entweder Abstellen des fälschlichen Wertes null an dieser Stelle wenn verboteten oder bei akzeptablen Wert null Umgang damit einbauen, null-Test

    mit Alternativen wie leere Liste merkt man es ggfs. nicht,
    bei 100% nie auch nur einem Fehler beim Programmieren kein Problem,

    bei 100% nie einen Fehler in Testabdeckung auch nicht so schlimm, wobei dort evtl. schwerer zu finden wenn am Ende nur Test nicht aufgeht,
    aber da kommt ja dann noch die Detail-Tests für jede Mini-Funktion hinzu,

    außerdem überhaupt die Frage, jeden Code mit aufwendigen Tests auszustatten..,
    hat @Sen-Mithrarin für Monopoly - Spiel sicher auch schon auf dem Plan , oder wenn nicht dann selber schuld und eh alles egal?
    gibt nicht nur diese Art Programmierung..
    (freilich 'mit null' genauso nur eine Art Programmierung )

    -------

    Nochmal: Gib mir ein valides Beispiel, wo der Unterschied, ob eine Collection leer oder NULL ist ein anderes Verhalten bedeutet, und diese Situation nicht bereits vom Ersteller der Liste erkannt (und per Exception kommuniziert) werden könnte.
    da wo zwischen null und Collection leer als valides Ergebnis zu unterscheiden ist, wirft eh niemand Exception, weil eben valides Ergebnis..

    Beispiel:
    Forum-Server: Map als Cache Suchstring, Liste Suchergebnisse, manche leer

    aktueller User kommt mit Suchstring X, Server will lieber alte Ergebnisse anzeigen als neu suchen, was zu tun?

    in der Map sind Ergebnisse null vs. leere Liste wichtige Unterscheidung,
    (Alternative evtl. contains, Optional usw.)

    ---------

    der andere Fall ist, dass Ergebnis null verboten ist, erlaubte Ergebnisse nur leere Liste oder gefüllte Liste,

    hier kann es schlicht als Fehler passieren (Fehler kommen vor!) dass beim Erstellen der Liste das Erkennen noch nicht umgesetzt ist
    -> wenn null im Fehlerfall zurückgegeben merkt man sofort dass ein Fehler vorliegt und kann diesen Fehler bald korrieren,
    wenn leere Liste im Fehlerfall zurückgegeben dann diesen Fehler vielleicht lange Zeit nicht bemerkt, die leere Liste als valides Ergebnis hingenommen

    supertolle Testabdeckung deckt es sicher auch auf, klar,
    supertolle Programmierer vergessen auch nie was, klar..

    mit null wird dagegen jedes simple 10 Zeilen-Programm vergleichsweise narrensicher,
    für alle Programmierer der Welt, ohne zwingende Ausführung in Komplettumgebung mit JUnit, Maven, .. Versionsverwaltung, Komplettest alle X Minuten usw.

    edit:
    und auch in den besten komplexen Umgebungen kann null nebenher mitspielen, nicht störend sondern gut integrierbar,
    veraltet nicht durch höhere Tools und Testabdeckung,
    so dass Fehler bei jeder direkten Ausführung sofort zu finden, nicht erst beim nächsten allgemeinen Test-Durchlauf
    Geändert von SlaterB (17.06.2016 um 13:21 Uhr)
    Hansa wird Meister

  17. #15
    User Floppy Disc Avatar von Sen-Mithrarin
    Registriert seit
    26.10.2013
    Fachbeiträge
    756
    Genannt
    63 Post(s)
    @SlaterB
    Muss gestehen - ich versteh nicht wirklich worauf du anspielst. Mag auch am aktuellen Zustand Urlaub -> Hirn aus liegen =P
    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?"

  18. #16
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    du solltst nicht umfangreiche Unit-Tests bei deinem Programm vergessen ,

    wäre jedenfalls eine empfehlenswerte Möglichkeit für erhöhte Codesicherheit,
    aber hier als Beispiel angebracht, dass für normale Programme doch eher übertrieben, je nach Einstellung dazu
    Hansa wird Meister

  19. #17
    User Megabyte Avatar von Timothy_Truckle
    Registriert seit
    01.08.2013
    Ort
    Wasserkuppe
    Fachbeiträge
    1.330
    Genannt
    86 Post(s)
    Blog-Einträge
    5
    Zitat Zitat von SlaterB Beitrag anzeigen
    außerdem überhaupt die Frage, jeden Code mit aufwendigen Tests auszustatten
    Das ist keine Frage:
    aufwendige Tests werden nicht gemacht, dafür aber UnitTest und zwar bevor der ProduktivCode geschrieben wird.

    Zitat Zitat von SlaterB Beitrag anzeigen
    in der Map sind Ergebnisse null vs. leere Liste wichtige Unterscheidung,
    as ist aber nicht das Beispiel nach dem ich gefragt habe, denn das VERHALTEN ist das selbe, ob die Liste nun leer ist oder ein NULL.

    Das Beispiel mit der Initialisierung war da schon besser, auch wenn es da geeigneteren Patterns für gäbe...


    Zitat Zitat von SlaterB Beitrag anzeigen
    supertolle Testabdeckung deckt es sicher auch auf, klar,
    supertolle Programmierer vergessen auch nie was, klar..
    Supertolle Programmieren arbeiten TDD (oder wenigsten Test first), also nein!


    Zitat Zitat von SlaterB Beitrag anzeigen
    mit null wird dagegen jedes simple 10 Zeilen-Programm vergleichsweise narrensicher,
    NEIN!
    Wer NULL bewust einsetzt macht grundsätzlich etwas falsch. Inband-Fehlersignalisierung ist immer Mist, auch in 10-Zeilen Programmen.


    Zitat Zitat von SlaterB Beitrag anzeigen
    für alle Programmierer der Welt, ohne zwingende Ausführung in Komplettumgebung mit JUnit, Maven, .. Versionsverwaltung, Komplettest alle X Minuten usw.
    JUnit ist (wie die IDE und die JVM selbst) Minimalausstattung!
    Der Rest gehöhrt zum Profi. Der Laie mag darauf verzichten. Aber dass ist schon wieder ein anderes Thema.


    Zitat Zitat von SlaterB Beitrag anzeigen
    und auch in den besten komplexen Umgebungen kann null nebenher mitspielen, nicht störend sondern gut integrierbar,
    veraltet nicht durch höhere Tools und Testabdeckung,
    Eine NPE kann passieren. Programmierer sind auch nur Menschen.
    Wer mir aber eine API anbietet, aus der ich NULL zurückbekomme, wo ich eine Collection erwarte muss mit entsprechend heftigen Reaktionen meinerseits rechnen...


    bye
    TT

  20. #18
    Projekt-Moderator Butterfaces Halbes Megabyte Avatar von Sym
    Registriert seit
    31.07.2013
    Fachbeiträge
    576
    Genannt
    28 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Mit anderen Worten, Du hast in Deinem Programm keinen dedizierten Initialisierungsprozess. Auch da ist die NULL-Liste ein Symptom für ein Problem.
    Doch natürlich sollte man sicherstellen, dass ein Objekt korrekt initialisiert ist. Im Falle eines Caches aber z.B. nutze ich so ein Konstrukt häufiger. Ist es null, muss der Cache erst noch aufgebaut werden. Ist die Liste leer, gibt es keine Daten. Lazy-Caching nutze ich tatsächlich häufiger.
    www.butterfaces.org = JSF 2 + Bootstrap + JQuery = awesome
    https://github.com/larmic

  21. #19
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.710
    Genannt
    285 Post(s)
    Zitat Zitat von Timothy_Truckle Beitrag anzeigen
    Zitat Zitat von SlaterB Beitrag anzeigen
    in der Map sind Ergebnisse null vs. leere Liste wichtige Unterscheidung,
    as ist aber nicht das Beispiel nach dem ich gefragt habe, denn das VERHALTEN ist das selbe, ob die Liste nun leer ist oder ein NULL.
    ?
    das Verhalten ist doch unterschiedlich, ganz allgemein nach Cache:
    - wenn null in der Map/ im Cache gefunden, dann ist die Suche erst noch auszuführen,
    - wenn dagegen ein Ergebnis gefunden (ob Liste, leer oder voll, oder sonstiges Objekt), dann dies einfach anzeigen

    kommt immer eine leere Liste, auch für den null-Fall, ist schwer zu unterscheiden ob die leere Liste für valides Ergebnis mit 0 Einträgen steht oder noch keine Suche ausgeführt,
    null ist sicher, anderes kann verwechselt werden
    Hansa wird Meister

  22. #20
    User Kilobyte Avatar von Clayn
    Registriert seit
    26.08.2013
    Fachbeiträge
    138
    Genannt
    18 Post(s)
    Gut dass es, im Falle einer Map, computeIfAbsent gibt

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

Direkt antworten Direkt antworten

In welcher Stadt steht der Eiffelturm?

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
  •