Diskussion:Assertion (Informatik)

Der Artikel ist meiner Meinung nach Java-lastig.

Beim zweiten Codebeispiel fehlt die Auflösung, welchen Denkfehler der Programmierer gemacht hat. Scheint ein Insider Joke zu sein.

Habe inzwischen das Codebeispiel gelöscht. Scheint mir nicht sinnvoll gewesen zu sein. --Mulno 16:43, 10. Jun 2005 (CEST)

Die Verbindung zu Eiffel, DBC und JUnit sollten näher beschrieben werden. --Mulno 21:52, 1. Mai 2005 (CEST)

Evtl. sollte man auch mal gucken in welchen anderen, populären Programmiersprachen es eine native Unterstützung für Assertions gibt. Bin die Tage schon über C# gestolpert. JensKohl 11:39, 7. Mai 2005 (CEST)

Überarbeitet

Auch wenn ich die bisherigen Anmerkungen erst jetzt gelesen habe, denke ich meine Umarbeitung stößt nicht auf Wiederspruch. Ich war also mal wieder "mutig".

Die Struktur habe ich verändert. Das Intro ist nun kurz (vielleicht immer noch ein bisschen unverständlich für Nichtprogrammierer). Ich habe aus dem ursprünglichen Material Absätze zu "Anwendung", "Geschichte" und "Programmierpraxis" gemacht.

Die Programmierpraxis hat noch ein paar Beispiele und Tipps hinzubekommen, denn die Schwierigkeit, Assertions von "normaler" Fehlerbehandlung zu unterscheiden ist nach meiner Erfahrung unter Programmierern verbreitet. (Daher auch die verrückte Idee assert mit NDEBUG zu koppeln, hier haben schon die C- und C++-Compilerhersteller und damit Lieferanten der Standardbibliotheken was nicht veratanden)

Die näheren Ausführung zu Modultests habe ich hier gestrichen, denn die gehören alle nach dort, und sind dort sicherlich auch zu (bald?) finden ).

Danke für die Aufmerksamkeit --11:42, 6. Okt. 2007 (CEST) huch, bei Signatur vertippt --Peu 13:04, 6. Okt. 2007 (CEST)

Umformulieren des Quelltextes

Das Beispiel ist insofern ungünstig, als es die Lesbarkeit des Funktionsaufrufes verringert: genderStr(GENDER_FEMALE) ist offensichtlich, während bei genderStr(true) die Bedeutung des Parameters true nicht unmittelbar ersichtlich ist.

Hier hast du einerseits Recht, allerdings würde der Funktionsaufruf typischerweise nicht so lauten, sondern so: genderStr(isFemale), d.h. die Variable wäre nicht nur entsprechend typisiert, sondern auch benannt. Übrigens kann im Prinzip jede Methode, die in einem Parameter ausschließlich literalen Argumenten aufgerufen wird, in eine mehrere Methoden zerlegt werden, die um dieses Argument rezuziert sind. Also z.B. setEnabledState(true) und setEnabledState(false) umwandeln in activate() und passivate(). Gruß --Peu 23:16, 13. Okt. 2007 (CEST)

Defekte in der umgebenden Hard- oder Software

Assertions sind m. E. nicht dazu da, "Defekte in der umgebenden Hard- oder Software" zu erkennen.

denn natürlich kann es während der Laufzeit eines Programms dazu kommen, dass 2+2=4 einmal nicht gilt, z.B. weil Variablen durch Programmfehler im Betriebssystem überschrieben wurden. -- Was willst du damit sagen?

Oefe 14:28, 8. Okt. 2007 (CEST)

sorry, vielleicht hast du damit zu wenig Erfahrung, Hardwaredefekte zu erkennen ist in der Tat ein Ziel des Einsatzes von assert. Übrigens gibt es keinen Grund anzunehmen, dass programminterne Größen nicht durch Fehler im Betriebssystem (z.B. DLLs in Windows) überschrieben werden könnten. Natürlich ist assert in erster Linie ein Mittel die Fehler aus dem eigenen Hause -- die Fehlerursache Nummer 1 -- zu erkennen. Wozu sollte man assert deiner Meinung nach einsetzen? --Peu 23:07, 13. Okt. 2007 (CEST)

Zusicherungen zur Kompilierzeit

Das "#if sizeof(int) != 4" Beispiel dürften nur mit sehr exotischen C++ Kompilern funktionieren und ist von daher kein gutes Beispiel für eine Zusicherung zur Kompilierzeit in C++. --91.96.58.89 22:57, 2. Jun. 2008 (CEST)

Falsch. Der C-Standard erfordert, genau wie der C++ Standard, dass sizeof(type-name) zur Kompilierzeit ausgewertet wird (C99 6.6/6, C++ 5.19/1, Stichwort: integer constant expression). Exotisch (genauer: unbrauchbar) wären also Compiler, die sich an dem – übrigens völlig gängigen und damit exzellent gewählten – Beispiel verschlucken. ^{(Sig. nachgetragen)}--IrrwahnGrausewitz ^blah 00:21, 21. Sep. 2010 (CEST)

Falsch. Bevor die integer constant expression ausgewertet werden kann, werden in einem #if alle Worte, die keine Makros sind, durch "0" ersetzt (C99 6.10.1, C++98 16.1, "there simply are no keywords"). Der einzige mir bekannte Compiler, der das verdaut, ist der von Borland (probiert: gcc, Watcom, DigitalMars). Deswegen greift man ja nur zu solchen Tricks wie int a[sizeof(int)==4].--Streu 23:35, 18. Nov. 2010 (CET)

Ausnahmen

Auch in Eiffel werden Ausnahmen geworfen, wenn eine Zusicherung nicht erfüllt ist.

Sicher, dass "Ausnahmen werfen" eine im Deutschen gültige Übersetzung von throw exceptions ist? Klingt eigenartig. ;) --141.24.93.165 13:11, 4. Feb. 2008 (CET)

Warum sollte die Übersetzung ungültig sein? Ich arbeite ja nun schon ein paar Jährchen als Softwareentwickler, und zumindest in meinem Umfeld ist das alltäglicher Sprachgebrauch. --j ?! 18:25, 5. Feb. 2008 (CET)

zweite Verwendung von Assertion

Assertion wird ebenfalls in der Linguistik verwandt. Könnte hierzu vielleicht jemand einen Artikel verfassen?

siehe hierzu auch: Sprechakttheorie (nicht signierter Beitrag von 141.2.139.187 (Diskussion) )

Meinst du eventuell Assertorische Aussage? Oder ist das nochmal was anderes? --j ?! 19:35, 2. Apr. 2008 (CEST)

Habe die diesbezüglichen Artikel heute verschoben ... Hafenbar 15:53, 24. Jun. 2008 (CEST)

Jetzt gefällt mir die Gewichtung nicht. Ich denke nämlich nicht, dass die Assertorische Aussage so viel wichtiger ist als der Begriff der Informatik, dass sie das Lemma für sich reklamieren darf. Besser fände ich eine Begriffsklärungsseite Assertion, die zwischen Assertorische Aussage und Assertion (Informatik) differenziert. --j ?! 19:19, 25. Jun. 2008 (CEST)

überarbeiten

"auch wenn es politisch korrekter wäre, enthält das folgende Beispiel eine (scheinbar) absurde Fehlermöglichkeit:" Was auch immer damit gemeint ist... bitte genauer erklären oder anderes Beispiel nehmen. 87.78.26.207 03:57, 26. Jan. 2014 (CET)

done --Sebastian.Dietrich ✉ 09:39, 26. Jan. 2014 (CET)