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

• kein Programmabbruch erfolgt
• keine Schäden am System entstehen
• die Funktionalität des Programmes gewährleistet bleibt
• der Benutzer auf Grund einer Fehlermitteilung in die Lage versetzt wird, Fehlerursachen selbst zu erkennen, zu beseitigen oder zu vermeiden
• ...

• Programmfehler (Typfehler, ungetesteter Code, fehlerhafte Zeiger, ...)
• Unerwartete Inputdaten (Division durch 0, Überlaufsprobleme, ...)
• Hardwarefehler (Festplattenfehler, ...)
• ...

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:

• Name des Subsystems
• Name des Moduls (Files)
• Name des Unterprogramms
• Beschreibung des Fehlers

• Verschiedene Fehler haben die gleiche Fehlernummer.
• Die Fehlernummer ist nicht auf der Liste.
• Es existieren unterschiedliche Fehlerlisten.
• Die Fehlerliste wurde so oft fotokopiert, daß diese nicht mehr lesbar ist.
• Die Fehlerliste ist verschwunden.

HermannWacker

Crash Only Software

"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

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