Laufzeit Fehler
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Meist sind mit LaufzeitFehler solche Fehler gemeint, die von einem Programm nicht ausreichend vorhergesehen und abgefangen werden, sodass sie - zumeist nach einer mehr oder weniger kryptischen Fehlermitteilung (z. B. "Laufzeitfehler 5341", Stack-Trace oder UAE) - zu einem Programmabbruch führen.

Der Programmabbruch an und für sich kann schon ein Problem darstellen, weil der Anwender diesen mit Recht als gravierenden Qualitätsmangel empfindet. Der Programmabbruch kann aber auch reproduzierbar eine bestimmte Funktionalität des Programmes beeinträchtigen. Schlimmer noch: es können durch den Abbruch Störungen im System auftreten (mangelnde Resourcenfreigabe, defekte Files, etc.) die zusätzliche Wartungstätigkeiten erfordern.

Es ist eine der wichtigsten Aufgaben des Entwicklers, mögliche Fehlersituationen vorherzusehen und durch entsprechenden Code oder Fehlermitteilungen so zu entschärfen, dass

Mögliche Ursachen für Laufzeitfehler:

Ein Laufzeitfehler ist immer ein Hinweis darauf, dass man das Programm nicht ausreichend getestet hat. Während der Entwicklung und der Integration kann es natürlich zu Laufzeitfehlern kommen. Es ist dann immer sehr hilfreich wenn in der Fehlermeldung die folgende Information in lesbarer Form enthalten ist:

Dies erfordert natürlich, dass man nicht nur die geforderte Funktionalität eines Programmes implementiert, sondern auch die Fähigkeit in die Applikation hinein programmiert einen Fehler zu erkennen und zu lokalisieren. Nach der Integration und dem Testen der Software sollten dann diese Fehlerroutinen nicht mehr aufgerufen werden (die Software ist hoffentlich fehlerfrei). Wenn dennoch ein Fehler auftritt, sollte dieser aufgrund der vorhanden Fehlerlokalisierungsfähigkeit der Software schnell entdeckt und behoben werden. Ich habe mir übrigens angewöhnt nicht lange nach Fehlern zu suchen sondern die Selbstanalysefähigkeit des Programmes zu erhöhen, wenn Fehler auftreten. Die Verwendung von Fehlernummern ist ein Anachronismus aus einer Zeit als man für Fehlermeldungen im Code zuwenig Speicherplatz hatte. Dies hat sich aber so eingebürgert, daß auch in modernen Softwareprojekten weiterhin Fehlernummern definiert werden. Dies hat dann zur Folge, daß man Fehlerlisten verwalten und konsistent halten muß was bei einem großen Software Projekt mit vielen Entwicklern häufig zu einem Problem wird. Beispiele: Siehe auch AdaExceptionHandler als Beispiel.

HermannWacker


Siehe auch: Crash Only Software für einen anderen Ansatz zu Laufzeitfehleren.
Diskussion
"Ich habe mir übrigens angewöhnt nicht lange nach Fehlern zu suchen sondern die Selbstanalysefähigkeit des Programmes zu erhöhen, wenn Fehler auftreten.": Spaßige Sache, wäre nett, wenn du uns den Code zur Verfügung stellen würdest oder einen groben Abriss gibst, wie man sowas macht. -- VolkerGlave

Mit ein paar Zeilen Code kann man natürlich keine allgemeingültige Lösung herbeizaubern, da das Vorgehen von der Programmiersprache, dem Betriebsystem und den Vorgaben des Projektes abhängig ist. Ein Beispiel habe ich unter AdaExceptionHandler eingetragen. -- HermannWacker

"Die Verwendung von Fehlernummern ist ein Anachronismus aus einer Zeit als man für Fehlermeldungen im Code zuwenig Speicherplatz hatte. ... Dies hat dann zur Folge, daß man Fehlerlisten verwalten und konsistent halten muß was bei einem großen Software Projekt mit vielen Entwicklern häufig zu einem Problem wird." Diese Behauptungen halte ich für sehr undifferenziert. In meinem aktuellen Projekt (C, embedded, 3 Entwickler) muss ich mit 8KB ROM auskommen. Hier hast Du nur dann eine Chance, wenn Fehlercodes verwendet werden. In diesem Fall haben die Fehlercodes zusätzlich eine gewisse Systematik und dienen zum Umschalten in diverse Notlauffunktionen. Werden Fehlercodes in einer zentralen Header-Datei (z.B. err_code.h) definiert und kommentiert, sollte es ein leichtes sein, diese zu pflegen. Das extrahieren einer Excel-Liste oder was auch immer, sollte kein grösseres Problem darstellen. Die anderen Anmerkungen sind nur faule Ausreden dafür, dass sich der/die Programmierer nicht genügend Gedanken gemacht haben. Allerdings sehe ich wohl ein, dass man auf grossen Maschinen sehr schnell aus dem Blick verliert, dass auch heute noch die meisten Systeme (Stückzahlen/Wert) Mini- oder mikro-Systeme sind. JoZi

Bei dem von dir beschriebenen System hast du natürlich kaum eine andere Möglichkeit als so vorzugehen. Meine Kritik bezieht sich aber auf Projekte die genügend Speicherplatz haben, aber Methoden aus einer Zeit verwenden, als Speichermangel bei Software-Projekten der Standard war. Bei Hardware naher Softwareentwicklung für Systeme, die in großen Stückzahlen produziert werden kann auch heute noch Speicherplatz eine Kostenfrage sein. Man muß sich dann die Frage stellen, ob man das Geld in die Fehlersuche und Speicheroptimierung steckt (Arbeitsstunden für Softwareentwickler) oder in die Hardware (größere Speicherbausteine). HermannWacker

Man kann beobachten, dass Entwickler recht unterschiedliche Einstellungen zur Qualität im Bereich der Fehlerbehandlung haben. Wer z. B. das Swing-Demoprogramm von Sun mit zuwenig Speicher startet (z. B. limitiert auf nur 20 MB), der wird feststellen, dass das System sehr unelegant und sogar ohne Fehlermitteilung abschmiert ... Als Entwickler und Benutzer würde ich mir zumindest eine Mitteilung "Programm wird wegen Speichermangel abgebrochen" wünschen. -- HelmutLeitner

Das spricht aber nicht für die Virtuelle Maschine. Ich hätte erwartet, dass zumindest die meckert. Ein Beispiel aus SpracheSmalltalk: In VisualWorks ruft die VM ab einem per Policy einstellbaren Limit eine vom Entwickler änderbare Callback-Routine auf. -- SaschaDördelmann


KategorieSoftwareQualität
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 30. April 2005 10:31 (diff))
Suchbegriff: gesucht wird
im Titel
im Text