Diskussion:Programmfehler
aus Wikipedia, der freien Enzyklopädie
Bugs im Englischen sind auf deutsch Wanzen und nicht Käfer! Hallo, liebe Leute. Mit Bug kann zwar auch mal ein Käfer gemeint sein. In der Regel gibt es aber zwei Worte für Käfer: Beetle und Chafer, die eher das audrücken, an was Deutsche beim Wort Käfer denken. Bug heisst auf Deutsch zunächst mal: Wanze und nicht Käfer(z.b. Bedbug= Bettwanze). Ja, da sind wir bei den weniger erfreulichen Krabeltieren. Genau das ist die erweiterte Bedeutung von Bug: Ungeziefer, Insekten, Schaben - Krabelzeugs. Ein Käfer ist natürlich auch ein Insekt nur: Wer denkt bei Käfer schon an Motten oder Schaben? Spätestens, wenn die Herkunft des Begriffes "Bug" über "Motte" versucht wird zu erklären, führt diese typisch deutsche Falschübersetzung von Bug als Käfer zur Verwirrung. Bug ist nicht Käfer sondern alles, was das Skelett aussen hat und mit Kammerjäger in Werbindung gebracht wird: Ungeziefer. --[[Benutzer:84.56.14.8|84.56.14.8] 08:15, 17. Sep. 2006 (nachträglich signiert von Bodo Thiesen)
- Mag zwar stimmen, aber unter einer Wanze verstehe ich, wenn es nicht ums Tierreich geht, eine Abhörvorrichtung. Mag zwar jetzt nur ein schwaches Argument sein, aber Bug heißt nun mal (auch) Käfer. Schlußendlich wird das deutsche Wort sowieso nicht benutzt, entweder findet man einen Bug oder einen Fehler, ich habe noch nie eine Wanze oder einen Käfer in einem Programm gefundne ;) --Bodo Thiesen 04:06, 11. Mär. 2008 (CET)
Es wäre nett hier noch etwas über Ausnahmebehandlung zu schreiben
- Dinge, die mit der Ausnahmebehandlung abgefangen werden können (und sollen) sind keine Programmfehler, sondern Fehler, die nicht im Zuständigkeitsbereich des Programmes liegen, aber dessen Ausführung beeinflussen (z.B. Datei nicht gefunden, zu wenig Speicher, zugriff verweigert). Diese nicht abzufangen ist zwar ein Programmfehler, die konkrete Ausnahmebehandlung und insbesondere das in der OOP übliche Konzept des Exception Handlings ist allerdings kein Programmfehler - in keine Weise. --Bodo Thiesen 04:13, 11. Mär. 2008 (CET)
Soweit ich weiß, hat man bei der Ariane-5 das bewährte Steuerungssystem der Ariane-4 verwendet. Der Prozessor war aber für die erhöhten Anforderungen der Ariane-5 zu langsam. Die Rakete kam dadurch so weit vom Kurs ab, dass sie gesprengt werden musste. Wenn das stimmt, wäre das kein Softwarefehler.
- Meines Wissens (übrigens auch nachzulessen in "Objektorientiertes Testen" von Uwe Vigenschow) kam es bei der Ariane 4 zu einem Integer Overflow. Genau 30 Sekunden nach dem Abheben erreichte die Ariane 5 ein Horizontalgeschwindigkeit von 32768 internen Einheiten des Sensors. Dieser Wert lage etwas fünfmal höher als beim Vorgängermodell Ariane 4, bedingt duch die höhere Schubkraft. Der redundant ausgelegte Reserverechner hatte das gleiche Problem bereits 72ms vorher und schaltete sich ab. Also doch ein sehr gutes Beispiel für einen Softwarefehler. --Gudi 10:59, 21. Jul 2006 (CEST)
-
- Nein, sowas kann halt passieren, wenn man Software zweckentfremdet. Die Software selber hat ihren Zweck im davor vorgesehenen System einwandfrei erfüllt - sie war für die Ariane 4 geschrieben und arbeitete dort wie vorgesehen. Das man sie unverändert (und scheinbar auch ungeprüft) in das Nachfolgemodell übernahm beweist ja, das die Ingenieure damit zufrieden waren. Ihr Fehler war, nicht nachzuprüfen, ob die alte Software kompatibel mit der neuen Hardware ist. Klarer Fall von Anwenderfehler... --213.61.162.162 16:41, 6. Jun. 2007 (CEST)
Aber wie wäre es damit: Ich habe gehört, dass ein großer Stromausfall in den USA in den 80er Jahren auf eine fehlende break-Anweisung in einem C-Programm zurückgeführt werden konnte. Weiß jemand mehr darüber?
--Juhox 20:41, 8. Sep 2003 (CEST)
Mir ist etwas unklar, warum der Beitrag nur Ada unter "siehe auch" gelistet hat. Ich persönlich würde hier anraten, auf Programmiersprachen#Besondere Ausprägungen weiter zu verweisen. -- Manny 17:01, 25. Feb 2004 (CET)
Inhaltsverzeichnis |
[Bearbeiten] Mariner 1
Im Artikel steht
- 1962 führte ein fehlender Bindestrich in einem Fortran-Programm zum Verlust der Venus-Sonde Mariner 1, welche über 80 Millionen US-Dollar gekostet hatte.
Aber im Artikel zu Mariner 1 steht
- Mariner 1 wurde aufgrund eines Fehlers in der Trägerrakete 290 Sekunden nach dem Start zerstört
Kann das jemand aufklären? --Sikilai 16:20, 2. Apr 2004 (CEST)
Laut diesem Nasa-Artikel ist Mariner 1 im wesentlichen aufgrund der Kombination zweier Fehler (einer davon war der fehlende Bindestrich) zu weit vom Kurs abgekommen und musste daher gesprengt werden. Es sind also beide Formulierungen korrekt. --Juhox 01:35, 3. Apr 2004 (CEST)
Es wäre meiner Ansicht nach sinnvoll, wenn wir es wie im Englischen üblich machen und vom Unterartikel Softwarefehler auf programmfehler verweisen. Ich persönlich halte Softwarefehler für den üblichen Terminus
Es sollte noch darauf hingewiesen werden, dass durch Programmfehler auch Probleme mit der Sicherheit von Computern und Daten auftreten koennen. Und das eben dadurch (z.B. keine Pruefung von Datenlaengen) auch Viren und aehnlichen auf einem Computer aktiv werden koennen. Also alle Folgen, welche durch die Ausnutzung eines Programmfehlers auftauchen koennen. Heutzutage ist ja der Absturz eines Programms fast noch das geringste Problem.
--Klmuell 09:58, 14. Jan 2005 (CET)
[Bearbeiten] Badewannenkurve
Warum in alles in der Welt sollte sich die Anzahl der Softwarefehler eines Programmes wie eine Badewannenkurve verhalten? Sind die Programme erst einmal den Kinderschuhen entwachsen sollten sie einigermaßen stabil sein. Ein Anwachsen der Fehlerzahl nach der stabilen Phase ist - so weit ich weiß - bisher bei keinem Program beobachtet worden. Geänderte Umgebungsbedingungen, wie Prozessoren der nächsten Generation und neuere Betriebssystemversionen sollten dabei unberücksichtigt bleiben. Also, weg mit der Badenwannenkurve, Softwarefehler während der Lebensdauer eines Programmes gehen gegen einen relativ kleinen Wert (hoffentlich Null). --217.87.76.253 21:20, 6. Mai 2006 (nachträglich signiert von JonnyJD)
- Bin selber Softwareingenieur und sehe das ebenso. MV --217.224.53.237 09:46, 8. Mai 2006 (CEST)
- Das halte ich für totalen Quatsch. Beim Thema Badewannenkurve denkt der studierte Software Engineer auch eher an eine andere Badewannenkurve, die mit dem hier beschriebenen Fehlerverhalten nicht besonders viel zu tun hat. Hätte gerne auch nur ein Beispiel einer größeren Software, bei der dies der Fall sein soll. -PG 10:39, 23.11. 2007
- Gründe für ein Ansteigen der Fehler in Abschnitt III:
- Funktionsanreicherung
- fortgeschrittenes Herumfutzeln beim Beseitigen von Bugs
- die Software ist technisch überholt oder muss neuen Anwendungsgebieten standhalten (die beim Design nicht vorgesehen waren)
- Sowas in der Art führt dazu, dass auch bei Software am Ende die Fehler wieder ansteigen. Man sollte das aber vielleicht auch geschickt im Artikel erklären und vielleicht auch mit einer Quelle belegen. Bin für Hilfe dankbar. --JonnyJD 02:47, 20. Apr. 2007 (CEST)
- Ich habe gerade entschieden, dass ich mich um einen Artikel Softwarealterung kümmern werde. Das dauert aber noch ein bisschen. --JonnyJD 15:20, 20. Apr. 2007 (CEST)
Ich habe jetzt einen Artikel zur Softwarealterung erstellt. Warum ihr geänderte Umgebungsbedingungen unberücksichtigt lassen wollt ist mir unklar. Geänderte Vorraussetzungen sind ja gerade der Grund warum viele Sachen (auch ausserhalb der Software) "veraltet" sind. -- JonnyJD 19:08, 23. Sep. 2007 (CEST)
[Bearbeiten] Laufzeitfehler vs semantische Fehler
Ich stimme nicht ganz damit ueberein, Laufzeitfehler und semantische Fehler gleichzusetzen. Unentdeckte semantische Fehler koennen zwar Laufzeitfehler hervorrrufen, aber sind nicht Fehler, die erst zur Programmlaufzeit als Fehler zum Vorschein treten. Zum Beispiel, in einer Programmiersprache mit einem strikten Typensystem sind Typfehler semantische Fehler, die ohne jegliche Programmausfuehrung schon als Fehler analytisch entdeckt werden koennen. Laufzeitfehler sind meinem Verstaendnis nach Fehler, die der semantischen Definition einer Programmiersprache zuwider laufen (z.B. den Typregeln), jedoch zur Laufzeit ein ungewuenschtes Ereignis oder Ergebnis produzieren. Ein klassischer Vertreter eines Laufzeitfehlers ist z.B. eine versuchte Division durch null in einem Ausdruck a/b wobei a und b numerische Variablen sind. Semantisch ist dieser Ausdruck korrekt, sofern a und b als numerische Typen auf denen eine Division erlaubt ist definiert sind. Nicht jeder Laufzeitfehler ist damit ein semantischer Fehler, zumindest wenn es um die Semantik der Programmiersprache geht. Mir faellt jetzt auch kein besserer Begriff ein, Fehler zu benennen, die durch einen unachtsamen Programmierer hervorgerufen werden (beispielsweise durch eine ungepruefte Division durch null). Vorschlaege meinerseits waeren "logischer Fehler" oder "systematischer Fehler", jedenfalls nicht semantischer Fehler. --82.41.49.115 01:47, 24. Jan. 2005 (nachträglich signiert von Bodo Thiesen)
- Ein Laufzeitfehler ist ein Fehler, der zur Laufzeit auftritt (gegenüber einem Fehler, der zum Zeitpunkt des Compilierens oder Linkens auftritt). Dabei ist es unerheblich, ob dieser Fehler durch das Fehlen einer Fehlerbehandlung (na, konnte die Datei geöffnet werden?), einen Tippfehler im Programm (a/b statt a&b) oder durch andere Dinge auftritt. Relevant ist einzig, daß das Programm nicht das tut, was es tun sollte. Ein semantischer Fehler ist ein nicht formaler Fehler, also auch ein Fehler, der sich durch erzwungene Typen-Checks nicht feststellen lässt. In C kann ich z.B. einen beliebigen Wert des Typs unsigned long in eine Variable des Typs unsigned char schreiben, und habe dabei 100% definiertes Verhalten. Wenn dabei wichtige Informationen verloren gehen, ist das ein semantischer Fehler. In C kann mir da aber die Technik (also der Compiler) nicht helfen, denn ich darf das machen, und in den meisten Fällen, in denen man das macht, will man das auch. Ada (kenne ich selbst nicht) soll wohl typensicherer sein, dort soll man auch Wertebereiche noch stärker eingrenzen können (z.B. diese Variable darf nur die Werte von 10 bis 50 haben, aber nicht die 23 und auch nicht die 42). Dort sind dann natürlich viel weitreichendere Prüfungen (formal) möglich, was aber eine Zuweisung des Wertes 42 zu dieser Variable zu einem formalen und damit nicht mehr semantischen Fehler macht. Dadurch wird er dann auch automatisch feststellbar. Ada schützt mich aber nicht davor, dort den Wert 15 rein zu schreiben, wenn ich doch eigentlich den Wert 25 reinschreiben wollte - das wiederum ist und bleibt ein semantischer Fehler. (Eine folgende Multiplikation mit 3 würde aber spätestens die Laufzeitumgebung erkennen, bei guten Compilern vielleicht schon dieser.) --Bodo Thiesen 04:37, 11. Mär. 2008 (CET)
---
Meiner Meinung nach (IMHO) gehört die Definition von Bug in diesem Beitrag und in dieser Beziehung an den Anfang des Artikels(!), um klarzustellen, dass es hier um einen software-Bug geht. --Angie 23:35, 25. Aug 2005 (CEST)
[Bearbeiten] Vage Behauptung
Es handelt sich hierbei lediglich um eine hopfeniduzierte Hyptothese, dennoch ich wage ich die Behauptung aufzustellen, dass ein Zusammenhang zwischen Bug und der deutschen Redewendung einen Bock geschossen haben bestehen könnte. Es ist nur eine intuitiv inspirierte Vermutung, doch sollte nicht schon allein die phonetische Nähe derer beiden zumindest als Anlass dienen, bei Gelegenheit in dieser Richtung nachzuforschen? Wäre es nicht zu schön, den linguistischen Bock bei der Erlegung der durchaus netten, doch reichlich unplausiblen Wanze zu beobachten? Wie gesagt, das alles ist rein spekulativ, doch meines Erachtens einer genaueren Betrachtung wert. Könnten nicht zur Geburtsstunde des Begriffes Ingeneure mit deutscher Muttersprache anwesend gewesen sein, aus deren Konversation ein englischssprachiges Teammitglied aus dem Satz "Wer hat hier den Bock abgeschossen" das Wort "Bock" aufgrund der klanglichen Ähnlichkeit als Käfer interpretiert haben?
- um das hopfeninduzierte mal weiterzuführen; ist der "Holzbock" nicht ein Käfer, womit wir wieder beim Bug wären... --CerealKiller 17:54, 11. Jun. 2007 (CEST)
