Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Mountain Lion: Absturz in vielen…
  6. Thema

Wie funktioniert das?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Wie funktioniert das?

    Autor: developer 03.02.13 - 23:43

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > 476f6c656d schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du kannst aber wiederum nicht auf jeden möglichen String testen. f
    > ile:///
    > > funktioniert ohne das etwas abstürzt.
    > > Es stürzt erst ab, wenn du das f groß schreibst.
    >
    > Sicherlich, aber Groß- und Kleinschreibung gehören eigentlich zum kleinen
    > 1x1 des Testen eines Parsers, und da hier eine spezielle Exception geworfen
    > wird, sollte der Test schon die Exception testen.

    Nein eigentlich hätte man einen Test schreiben müssen bei dem bekannt ist, dass er einen Fehler im Parser triggert.
    Das wäre dann ein Integrationstest.

    Mit deiner Groß / Kleinschreibung wärst du nicht weit gekommen es sei denn du hättest alle tokentypen des parsers durchtesten wollen... in jeder komponente.

    Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5

  2. Re: Wie funktioniert das?

    Autor: non_sense 04.02.13 - 08:46

    developer schrieb:
    --------------------------------------------------------------------------------
    > Um den Fehler zu provozieren hätte man ihn kennen müssen.
    > Unittests hätte da genau gar nichts geholfen solange niemand auf die Idee
    > kommt zu schaun ob genau dieser String Probleme macht.

    Da eine Exception geworfen wird, ist der Fehler bekannt ;)
    Vielleicht nicht in dieser Konstellation, aber in einer anderen. Der Fehler beruht ja darauf, dass auf diese Exception nicht reagiert wird. Nicht ohne Grund wurde dort eine Exception eingebaut. Folglich müsste es sogar noch weitere Zeichenketten geben, die diese Exception auslöst und ein Absturz verursacht.



    1 mal bearbeitet, zuletzt am 04.02.13 08:47 durch non_sense.

  3. Re: Wie funktioniert das?

    Autor: developer 04.02.13 - 15:09

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > developer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Um den Fehler zu provozieren hätte man ihn kennen müssen.
    > > Unittests hätte da genau gar nichts geholfen solange niemand auf die
    > Idee
    > > kommt zu schaun ob genau dieser String Probleme macht.
    >
    > Da eine Exception geworfen wird, ist der Fehler bekannt ;)
    > Vielleicht nicht in dieser Konstellation, aber in einer anderen. Der Fehler
    > beruht ja darauf, dass auf diese Exception nicht reagiert wird. Nicht ohne
    > Grund wurde dort eine Exception eingebaut. Folglich müsste es sogar noch
    > weitere Zeichenketten geben, die diese Exception auslöst und ein Absturz
    > verursacht.

    Wie bereits an anderer Stelle ewähnt müsste man das durch Integrationstests checken.

    Der Fehler wird in einem Parser geworfen, wenn es Tests für diesen gibt dann wird das auch bestimmt getestete. Der Parser könnte also zu 100% getestet sein ohne, dass das weiter auffällt, denn der Fehler tritt erst bei einer "falschen" Integration des Parsers in Erscheinung.

    Ein integrationstest der das erkennt hätte also kaputen Input für mindestens alle "Base" Exceptions in der Vererbungshirachie rein hauen müssen. ( Im Idealfall erben die hoffentlich alle von einer Parser Exception )

    Wie es scheint fehlt dir hier auch ein tieferes Verständnis wie tests für Parser gestalltet werden können und welche Probleme es bei dem kompletten Interface von Pasern zu lösen gibt.
    Von Problemen die in der langjährigen Weiterentwicklung von sehr großen integrierten Codemengen mit Teamfluktuation, Abwärtskompatibilitätsprobleme etc. auftreten ganz zu schweigen.

    Da der Fehler wohl erst mit der aktuellen Version auftritt besteht die Möglichkeit, dass diese Exception auch neu ist, somit das Interface geändert wurde was bei Exceptions häufig gar nicht als Interface Änderung wahr genommen wird und bei derart großen komplexen Projekten auch durchaus übersehen werden kann.

    Die Behauptung man könne das auf jeden Fall immer mit Unittests abfangen ist daher nichts anderes als die Behauptung man können fehlerfreie Programme in beliebiger Komplexität schreiben, denn alles in allem sind diese Tests auch Teil des Projektes.
    Spätestens jetzt sollte dir klar werden wie unsinnig diese Aussage also ist.

    Mit statischer Codeanalyse hätte man derartige Fehler theoretisch finden können so es denn Werkzeuge mit der notwendigen Komplexität überhaupt für die Sprache Platform gibt. Aber auch da sind längst nicht alle theoretisch entdeckbaren Fehlerklassen implementiert.

    Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5

  4. Re: Wie funktioniert das?

    Autor: non_sense 04.02.13 - 15:51

    Anscheinend verstehst du einfach nicht, dass der Parser schon eine Exception wirft.
    Folglich müsste es eigentlich ein Testfall geben, der überprüft, ob in bestimmten Konstellationen diese Exception geworfen und abgefangen wird. Die Exception ist ja bekannt und wurde von einem Entwickler explizit eingebaut.

    Es ist nun völlig unerheblich, ob der Parser nun "F*le:///" oder "a*sd:///" bekommt, wenn beide Zeichenketten die selbe Exception werfen. Da die Exception aber nicht abgefangen wird, passieren die Abstürze sowohl bei "F*le:///" als auch bei "a*sd:///".

    developer schrieb:
    --------------------------------------------------------------------------------
    > Da der Fehler wohl erst mit der aktuellen Version auftritt besteht die Möglichkeit,
    > dass diese Exception auch neu ist, somit das Interface geändert wurde was bei
    > Exceptions häufig gar nicht als Interface Änderung wahr genommen wird und bei
    > derart großen komplexen Projekten auch durchaus übersehen werden kann.

    Habe ich irgendwo das Gegenteil behauptet?
    Vielleicht solltest du dir noch mal meine Beiträge genauer anschauen, da ich nachgefragt habe, ob sie so ein Exot ist, oder neu hinzugekommen ist:

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > Naja, es kann auch noch weitere Konstellationen geben, die einen Absturz
    > verursachen. Es muss nur halt diese Exception geworfen werden. Ich frage mich, ob
    > diese Exception wirklich so ein Exot ist, so dass sie kaum vorkommt? Oder ist sie
    > vielleicht durch ein Update hinzugekommen, und es wurde vergessen, die oberen
    > Schichten zu aktualisieren?



    3 mal bearbeitet, zuletzt am 04.02.13 16:21 durch mb (Golem.de).

  5. Re: Wie funktioniert das?

    Autor: developer 04.02.13 - 16:17

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > Anscheinend verstehst du einfach nicht, dass der Parser schon eine
    > Exception wirft.
    > Folglich müsste es eigentlich ein Testfall geben, der überprüft, ob in
    > bestimmten Konstellationen diese Exception geworfen und abgefangen wird.
    > Die Exception ist ja bekannt und wurde von einem Entwickler explizit
    > eingebaut.

    Oh doch, das verstehe ich sehr gut.
    Ein Unittest für den Parser könnte das sogar aktuell prüfen, es würde nur nichts am Problem ändern, es sei denn diese Exception hätte vom Parser gefangen werden müssen und nicht von der einbindenten Applikation worüber wir allerdings keine Information haben.

    Ein Unittest des Parsers könnte diese Exception also ohne weiteres Abdecken, ohne dass das Problem erkannt wird.

    Dazu wäre ein Integrationstest nötig.
    Ich kann davon aus gehen, dass dir als Testverfechte die Unterschiede der Testarten geläufig sind?

    >
    > Es ist nun völlig unerheblich, ob der Parser nun "F*le:///" oder "a*sd:///"
    > bekommt, wenn beide Zeichenketten die selbe Exception werfen. Da die
    > Exception aber nicht abgefangen wird, passieren die Abstürze sowohl bei
    > "F*le:///" als auch bei "a*sd:///".
    >

    Das ist korrekt gibt aber nur das wider was ich bereits gesagt habe.

    >> Ein integrationstest der das erkennt hätte also kaputen Input für mindestens alle >> "Base" Exceptions in der Vererbungshirachie rein hauen müssen. ( Im Idealfall
    >> erben die hoffentlich alle von einer Parser Exception )


    > Habe ich irgendwo das Gegenteil behauptet?
    > Vielleicht solltest du dir noch mal meine Beiträge genauer anschauen, da
    > ich nachgefragt habe, ob sie so ein Exot ist, oder neu hinzugekommen ist:

    Nein, ich wiederum hab dir das aber auch nicht unterstellt sondern nur ebefalls aufgeführt und ich werde genau so wenig wie du das machst hier alle Beiträge Lesen um kleinere Redundanzen in den Aussagen zu vermeiden.

    Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5



    2 mal bearbeitet, zuletzt am 04.02.13 16:22 durch mb (Golem.de).

  6. Re: Wie funktioniert das?

    Autor: non_sense 04.02.13 - 16:35

    developer schrieb:
    --------------------------------------------------------------------------------
    > Oh doch, das verstehe ich sehr gut.
    > Ein Unittest für den Parser könnte das sogar aktuell prüfen, es würde nur
    > nichts am Problem ändern, es sei denn diese Exception hätte vom Parser
    > gefangen werden müssen und nicht von der einbindenten Applikation worüber
    > wir allerdings keine Information haben.

    Da jede Anwendung abstürzt, ist es unerheblich, welche Anwendung grad läuft.
    Entscheidend ist das verwendete Textfeld aus der API, die Apple für die Anwendungsentwicklung zur Verfügung stellt, da das Textfeld die Daten an den Parser weiterschickt. Also hätte der Unittest die API testen müssen und der Test ist nicht vollständig.



    1 mal bearbeitet, zuletzt am 04.02.13 16:36 durch non_sense.

  7. Re: Wie funktioniert das?

    Autor: theonlyone 04.02.13 - 16:45

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > developer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Oh doch, das verstehe ich sehr gut.
    > > Ein Unittest für den Parser könnte das sogar aktuell prüfen, es würde
    > nur
    > > nichts am Problem ändern, es sei denn diese Exception hätte vom Parser
    > > gefangen werden müssen und nicht von der einbindenten Applikation
    > worüber
    > > wir allerdings keine Information haben.
    >
    > Da jede Anwendung abstürzt, ist es unerheblich, welche Anwendung grad
    > läuft.
    > Entscheidend ist das verwendete Textfeld aus der API, die Apple für die
    > Anwendungsentwicklung zur Verfügung stellt, da das Textfeld die Daten an
    > den Parser weiterschickt. Also hätte der Unittest die API testen müssen
    > und der Test ist nicht vollständig.

    Sehe ich auch so.

    Man kann es sich hin oder her reden, am Ende wird eine Exception schlichtweg "planlos" weitergereicht in der Hoffnung irgendwer wird sich schon darum kümmern.

    Das passiert nicht und "krach" ist es kaputt.


    Seine API komplett zu testen und seine Exceptions alle in Tests zu provozieren sind schlichtweg notwendig, das nicht zu tun ist einfach "eingesparte" Zeit die einem irgendwann aufschlägt.

    Windows Phone hatte auch ein paar sehr lächerliche "Bugs" in denen man keine Listener an einen stink normalen "Button" anbringen konnte.

    Das war genauso peinlich und ist schlichtweg etwas das nicht getestet wird.


    Das zeigt eigentlich direkt das etwas Entwickelt wurde oder einen Tests dazu.

    Machst du das Test-Driven darfst du das schlichtweg garnicht machen, schreib deine Tests, dann hau den Code dazu der diesen Test erfüllt.

    Werden Exceptions ausgelöst, schreib Tests die diese Exceptions auslösen ; dabei musst du nicht jede Konstellation von Eingaben abfangen, es genügt wenn alle Exeptions ausgelöst werden.


    Sorgt am Ende etwas zum crash das nirgends abgefangen wird, ist dein Problem deutlich tiefgreifender und kann tatsächlich als "unbekannt" gelten.

    Existieren Exceptions ist das Problem in keinem fall "unbekannt".

  8. Re: Wie funktioniert das?

    Autor: developer 04.02.13 - 16:47

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > developer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Oh doch, das verstehe ich sehr gut.
    > > Ein Unittest für den Parser könnte das sogar aktuell prüfen, es würde
    > nur
    > > nichts am Problem ändern, es sei denn diese Exception hätte vom Parser
    > > gefangen werden müssen und nicht von der einbindenten Applikation
    > worüber
    > > wir allerdings keine Information haben.
    >
    > Da jede Anwendung abstürzt, ist es unerheblich, welche Anwendung grad
    > läuft.
    > Entscheidend ist das verwendete Textfeld aus der API, die Apple für die
    > Anwendungsentwicklung zur Verfügung stellt, da das Textfeld die Daten an
    > den Parser weiterschickt. Also hätte der Unittest die API testen müssen
    > und der Test ist nicht vollständig.

    Du argumentierst immernoch auf Basis von Informationen die wir Beide nicht haben.

    Wie auch immer.
    Da wir anscheinend die ganze zeit inhaltlich ähnlich aneinander vorbei reden lass ich das jetzt mal gut sein bevor ich jetzt noch ne Diskussion zum Unterschied von Unittests und Integrationstest aufmache ohne das abschliesend geklärt werden kann was von beiden nun eigentlich nötig wäre.

    Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5

  9. Re: Wie funktioniert das?

    Autor: non_sense 04.02.13 - 17:02

    developer schrieb:
    --------------------------------------------------------------------------------
    > Du argumentierst immernoch auf Basis von Informationen die wir Beide nicht
    > haben.

    Wie gesagt, lies dir meine Beiträge genauer durch.
    Am besten gleich den ersten von mir in diesem Thread.
    Dort wirst du ein Link zu einer technischen Beschreibung finden, was passiert, wieso und von wem ausgelöst ;)

  10. Re: Wie funktioniert das?

    Autor: developer 04.02.13 - 17:48

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > developer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du argumentierst immernoch auf Basis von Informationen die wir Beide
    > nicht
    > > haben.
    >
    > Wie gesagt, lies dir meine Beiträge genauer durch.

    Siehst du genau das halte ich nicht für abschliesend geklärt (ok doch schon) wer eigentlich genauer nachlesen sollte ;-)

    > Am besten gleich den ersten von mir in diesem Thread.
    > Dort wirst du ein Link zu einer technischen Beschreibung finden, was
    > passiert, wieso und von wem ausgelöst ;)

    Danke ich kenn den Stacktrace. Der kursierte schon ne Weile bevor es den ycombinator post gab, der nichts anderes macht als diesen nochmal zu erklären.

    Deine Beiträge hab ich schon ausreichend kommentiert.
    Unreflektierte mantraartige Verweise auf Unittests auf Basis auf Basis des Wissens was schief gelaufen ist bringen nicht wirklich eine Erkenntnis wie es denn hätte laufen müssen auch wenn ich mir sicher bin, dass du das für dich schon abschliesend geklärt hast.

    Es sei denn du kennst die genaue Architektur und die vollständige API und weiß wo genau die Exception nach der Architektur eigentlich hätte gefangen werden müssen...

    Es ist nicht klar ob es die API kaupt ist. Es könnte genau so gut sein, das es an der Integration lag auch wenn ich gelernt habe, dass du da anscheinend nicht wirklich differenzierst.

    Na ja ich verabschiede mich mal an der der Stelle aus der Diskussion das bringt nichts.

    Whatever you do, do it with: 5 + (sqrt(1-x^2(y-abs(x))^2))cos(30((1-x^2-(y-abs(x))^2))), x is from -1 to 1, y is from -1 to 1.5, z is from -100 to 4.5

  11. Re: Wie funktioniert das?

    Autor: non_sense 04.02.13 - 18:17

    developer schrieb:
    --------------------------------------------------------------------------------
    > Es sei denn du kennst die genaue Architektur und die vollständige API und
    > weiß wo genau die Exception nach der Architektur eigentlich hätte gefangen
    > werden müssen...

    Wo ist auch für diese Diskussion völlig egal, da wir kein Bugfixing betreiben. Die Exception muss irgendwo dem Parser und dem Textfeld abgefangen werden, aber sie wird nicht abgefangen und die Anwendung stürzt ab. Fazit: Der Test der API ist nicht vollständig, da dies beim Test hätte auffallen müssen. Mehr können wir nicht sagen und mehr wurde hier auch nicht gesagt. Wenn du meinst, du müsstest mehr hineininterpretieren, als hier steht, dann ist es dein Pech ;)

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. geobra Brandstätter Stiftung & Co. KG., Zirndorf bei Nürnberg
  2. Bosch Software Innovations GmbH, Waiblingen
  3. Mediengruppe RTL Deutschland GmbH, Köln
  4. Bosch Gruppe, Abstatt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-74%) 7,77€
  2. 50,99€ mit Vorbesteller-Preisgarantie
  3. (-80%) 1,99€
  4. 32,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smartphone von Gigaset: Made in Bocholt
Smartphone von Gigaset
Made in Bocholt

Gigaset baut sein Smartphone GS185 in Bocholt - und verpasst dem Gerät trotz kompletter Anlieferung von Teilen aus China das Label "Made in Germany". Der Fokus auf die Region ist aber vorhanden, eine erweiterte Fertigung durchaus eine Option. Wir haben uns das Werk angeschaut.
Ein Bericht von Tobias Költzsch

  1. Bocholt Gigaset baut Smartphone in Deutschland

Indiegames-Rundschau: Schiffbruch, Anime und viel Brummbrumm
Indiegames-Rundschau
Schiffbruch, Anime und viel Brummbrumm

Gas geben, den weißen Hai besiegen und endlich die eine verlorene Socke wiederfinden: Die sommerlichen Indiegames bieten für jeden etwas - besonders fürs Spielen zu zweit.
Von Rainer Sigl

  1. Indiegames-Rundschau Spezial Unabhängige Riesen und Ritter für Nintendo Switch
  2. Indiegames-Rundschau Schwerelose Action statt höllischer Qualen
  3. Indiegames-Rundschau Kampfkrieger und Abenteuer in 1001 Nacht

Windenergie: Wie umweltfreundlich sind Offshore-Windparks?
Windenergie
Wie umweltfreundlich sind Offshore-Windparks?

Windturbinen auf hoher See liefern verlässlich grünen Strom. Frei von Umwelteinflüssen sind sie aber nicht. Während die eine Tierart profitiert, leidet die andere. Doch Abhilfe ist in Sicht.
Ein Bericht von Daniel Hautmann

  1. Hywind Scotland Windkraft Ahoi

  1. Klage eingereicht: Tinder-Mitgründer fordern Milliarden von Mutterkonzern
    Klage eingereicht
    Tinder-Mitgründer fordern Milliarden von Mutterkonzern

    Bei der Dating-App Tinder ziehen Mitarbeiter der ersten Stunde vor Gericht. Der Mutterkonzern soll sie mit manipulierten Finanzdaten um Milliarden US-Dollar gebracht haben.

  2. Verizon: Erste 5G-Angebote in den USA mit Google und Apple
    Verizon
    Erste 5G-Angebote in den USA mit Google und Apple

    Verizon Communications startet noch dieses Jahr 5G als Fixed-Wireless. Mit im Paket sind Videoprodukte von Google und Apple.

  3. IT-Sicherheit: Die smarte Stadt ist angreifbar
    IT-Sicherheit
    Die smarte Stadt ist angreifbar

    Es war zum Glück eine Falschmeldung, dass Hawaii mit Raketen angegriffen wird. Aber sie sorgte für reichlich Verunsicherung unter den Bewohnern. Panik kann eine starke Waffe sein - und sie auszulösen ist nicht so schwierig, wie Sicherheitsforscher herausgefunden haben.


  1. 14:54

  2. 14:29

  3. 14:11

  4. 13:44

  5. 12:55

  6. 12:00

  7. 11:20

  8. 11:05