Fehlerbehandlung... ähm... mach ich später

[Micha]

Das ist nicht wirklich ein Hive spezifisches Thema, hat aber doch viel Bezug:

ich bin gerade am Basteln für SD-Karten Lese/Schreib Routinen für mein K1000 Projekt. Man probiert elementare Abläufe. Es klappt. Es klappt auch beim 10ten Versuch stabil. Und dann baut man aus den elementaren Sachen allmählich eine mehr oder weniger komplexe Anwendung, ungefähr so: "lies einen Block von SD-Card, stelle irgendwas verrücktes damit an, lies den nächsten Block, solange bis eine oder mehrere Bedingungen erfüllt sind".

Ja und da der Mensch faul ist sagt man dann erst mal: elementare Tests haben immer geklappt, ich schreib das Programm geradeaus. Ich nehme an, dass keine Fehler auftreten. Weil ich garnicht genau weiss welche Konsequenzen das hätte und wie und was und wann passieren könnte...
Fehlerbehandlung füge ich dann später zum Projekt hinzu. Das Problem: wir alle wissen im Grunde, dass später == nie bedeutet.

Frage an diejenigen hier die an Systemsachen basteln: wie macht ihr das? Erst mal ne simple Version, Fehlerbehandlung später, oder zwingt ihr euch selber den mühsamen Weg auf, Fehlerbehandlung gleich von vorneherein ordentlich zu machen? Vielleicht ist das ja ne Gewohnheitssache die man lernen kann(?)

[PIC18F2550]

Jedes Teil wird solange getestet mit Fehlern bis nur noch die gültigen befehle übrig bleiben.
Sonst würde wieder ein Windows entstehen.
Fehler Möglichkeiten müssen so früh wie möglich erkannt und ausgeschlossen werden.
Deshalb testen testen und testen bis der Arzt kommt.

[digger]

Wow, vorbildlich Pic ... wenn du das echt immer so durch ziehst dann alle Achtung von mir.
Meine Motivation eine Code weiter zu testen und zu optimieren sinkt rapide wenn der Code erstmal gut läuft. Ich zwinge mich dann immer sehr zum weitermachen. (Oft klappts mit dem zwingen nicht, falls nicht böse Konsequenzen drohen falls ein Fehler auftritt.)

[drohne235]

Da hat wohl jeder so seine eigene Methode.

Was ich mir angewöhnt habe: Nachzuhaken wenn es unerklärliche Effekte gibt, auch wenn sie aktuell keine negativen Auswirkungen haben. Meist stekct da ein Fehler dahinter, und nach meiner Erfahrung, wird dieser Fehler früher oder später zu einem echten Problem, nur das der Aufwand Fehler zu suchen später (bei größerer Komplexität) sich dann potenzieren kann.
Wenn so eine "Unerklärlichkeit" auftritt, ist das bei mir immer wie ein Splitter im Finger: Man sieht das Ding nicht, aber man fühlt immer mal wieder das es da ist und im Innersten weiß man, dass er raus muß.

So ein Beispiel war ein kleiner Fehler in der Busroutine im Hive. Symptome: Nach einem Reset war immer die unterste Speicherzelle im eRAM gelöscht. War zum damaligen Zeitpunkt nicht schlimm, aber hätte später zu massiven Problemen geführt. Aber es war extrem nervig nicht zu wissen, warum das passiert, denn es war völlig unlogisch. Ich hab damals ziemlich schlecht geschlafen...

Fehlerbehandlungen bastle ich meist relativ spät rein pragmatisch in die obersten Schichten der Software. Zu frühe Fehlerbehandlung frisst auch einiges an Performance und erzeugt selbst wieder Komplexität. Zur Fehlersuche "spiele" ich gern mit dem Code. Also einfach sinnlose und coole Sachen programmieren: dann ist es keine Fehlersuche, sondern hat einen gewissen Funfaktor und man testet automatisch. Der StarTracker war so eine spielerische "Fun-Fehlersuche". Bei einem Hobbyprojekt geht sowas natürlich problemlos.

[PIC18F2550]

Hi,
Es kommt darauf an wie ein Programm geschieben wird.
Ich versuche immer den wertebereich von Variabeln zu Prüfen bevor ich sie verarbeite.

Zu frühe Fehlerbehandlung frisst auch einiges an Performance und erzeugt selbst wieder Komplexität.

Weinachtsbaumprinzip
Der Fehler wird erst durch das System geschleift bevor er erkannt wird
Da muss ich doch in allen Programmen den selben Fehler behandeln
Fehlerhafte Software bringen fehlerhafte Systeme zur Welt. Sie sind unzuverlässig und verschwenden Zeit und Ressourcen.
Eine frühzeitige Kontrolle verringert die Komplexität.
Die Performance in einem Programm ist es vollkommen egal ob ein Wert vorher geprüft wird oder Hinterher, es benötigt immer die Selbe Zeit.
Der einzige Unterschied ist, das nach der Verarbeitung von Werten, sich im Anschluss, nicht immer ermitteln läst ob das Ergebnis Richtig oder Falsch ist, vorallen nicht in Komplexen Programmstruckturen.

Daher kann ich nur Raten wehret den Fehler und verschiebt sie nicht in das nächst höhere Programm.
Denn er tritt euch ins Schienbein wenn ihr es garnicht erwartet.

Code: Alles auswählen

PUB main | cmd,i,index                                  'chip: kommandointerpreter
''funktionsgruppe               : chip
''funktion                      : kommandointerpreter
''eingabe                       : -
''ausgabe                       : -

  init_subsysteme                                       'bus/vga/keyboard/maus initialisieren
  repeat
    i   := 0
    cmd := gc                                           'kommando empfangen
    case cmd
'       ----------------------------------------------  KEYBOARD
        1: key_stat                                     '1: Tastaturstatus senden
        2: key_code                                     '2: Tastaturzeichen senden
        4: key_spec                                     '4: Statustasten ($100..$1FF) abfragen
'       ----------------------------------------------  GRAPHICS
        'clear
        10: clear
        'copy(dest_ptr)
        11: copy(disp_base)
        'color(c)
        99: reboot                                      'bellatrix neu starten

Was passiert wenn cmd erst mit dem Wert 5 und anschließend mit 99 bedient wird???

Was machen die nachvolgenden Bytes???

Nur mal drüber Nachdenken.
Und nun eine schöne "gute Nacht".

[drohne235]

Hey, das muß man alles nicht so eng sehen denk ich.

Weinachtsbaumprinzip
Der Fehler wird erst durch das System geschleift bevor er erkannt wird

Du verstehst mich da falsch. Nehmen wir als Beispiel Forth. Nach deiner Theorie müsste ich schon bei der Implementierung elementarer Subroutinen auf Fehler prüfen, also (um es ganz krass darzustellen) müsste ich schon bei DUP oder SWAP den Stack prüfen, ob entsprechende Werte dort vorhanden sind, um einen Stackfehler zu vermeiden. Kann man machen, und das System ist dann auch schon in der Designphase sehr fehlertolerant, aber es ist entgegen deiner Theorie dann auch viel langsamer.

Die Performance in einem Programm ist es vollkommen egal ob ein Wert vorher geprüft wird oder Hinterher, es benötigt immer die Selbe Zeit.

Das ist falsch. Wenn man auf einer unteren Softwareschicht prüft, so baut man eine Fehlerprüfung in eine ausfaktorisierte Routine ein. Im Normalfall faktorisiert man eine Sequenz als extra Routine aus, da sie in mehreren anderen Routinen in der gleichen Form vorkommt und man so Speicher sparen kann und den Quelltext übersichtlicher gestaltet indem man abstrahiert. "Vorher" bedeutet also, dass die Fehlerprüfung viel öfter aufgerufen wird wenn sie in den ausfaktorisierten Sequenzen statt in der übergeordneten Struktur stattfindet, was schlicht und ergreifend Performance kostet. "Vorher" kann durch die Faktorisierung ja auch bedeuten "innerhalb einer Schleife" - in diesem Fall multipliziert sich der Performanceverlust eventuell sogar.

Dein Denkfehler bezüglich der Performance besteht darin, das du davon ausgehst, das eine Subroutine nur einmal in der darüberliegenden Schicht Verwendung findet, wie die Lampen in der Weihnachtsbaumbeleuchtung jeder Lampe nur eine weiter folgt, was so in der Praxis ja so gut wie nie auftreten sollte. Vielmehr wird zum Beispiel DUP und SWAP an tausend anderen Stellen in den übergeordneten Routinen verwendet - wir haben also nicht eine linear verkettet Weihnachtsbaumbeleuchtung, sondern eine hirarchisch aufgebaute Baumstruktur mit immer größerer Abstraktion.
Wenn ich nun in der übergeordneten Schicht die Fehlerprüfung einbaue, wird sie nur dort ausgeführt. Baue ich sie in die grundlegenden Routinen ein, wird die Fehlerprüfung eventuell extrem oft immer wieder ausgeführt, was die Performance in den Keller treibt.

Fehlerhafte Software bringen fehlerhafte Systeme zur Welt.

Wir reden aber hier nicht über fehlerhafte Software, sondern über Fehlerprüfung und fehlertolerante Routinen wärend dem Entwurfsprozess. Eine Routine in einer unteren Softwareschicht muss natürlich funktionieren (ist also nicht fehlerhaft), das steht nicht zur Frage. Aber muß sie auf jeder Ebene zum Beispiel gegenüber ihren Parametern für alle Fälle fehlertolerant sein? Natürlich kann ich bei Forth zum Beispiel, wenn ich einfach ein DROP eingeben ohne Wert auf dem Stack mit diesem einfachen Befehl ein Fehler inklusive Abort erzeugen, aber es ist nunmal mein Job als Programmierer zu wissen, dass man eine Schraube im Normalfall mit einem Schraubenzieher und nicht mit einer Säge entfernt - dafür muss ich auf dieser Ebene keine Fehlerprüfung einbauen, die einfach nur Leistung verbrennt.

Was passiert wenn cmd erst mit dem Wert 5 und anschließend mit 99 bedient wird???
Was machen die nachvolgenden Bytes???

Nur mal drüber Nachdenken.
Und nun eine schöne "gute Nacht".

Gutes Beispiel. Der Code stammt vom Bellatrix-Code des G0-Treiber. Der Kommandointerpreter ist dabei sehr einfach und die Reaktionen sind gut mit einem Blick in den Quelltext ablesbar: Da für cmd 5 kein Fall definiert ist und auch kein Default, wird dieser Code ignoriert und das folgende Byte wieder als Kommandocode interpretiert. Das folgende Byte cmd 99 löst regulär ein Reboot von Bellatrix aus, was bedeutet, dass der normale Texttreiber in Bella wieder aus dem Flash geladen und initialisiert wird. Nachfolgend kann also wieder mit den ganz normalen ios-Routinen für die Textausgabe gearbeitet werden.

Wo war da jetzt das Problem und wo sollte man dort die Fehlerprüfung einbbauen? Das unbekannte Codes ignoriert werden ist doch ok und das ein Reboot-Funktion den Chip in seinen Grundzustand versetzt ist auch genau das, was man erwartet. Aber ich vermute, du wolltest sagen, das halt schon in Bella eine Fehlerprüfung stattfinden soll. Ich bin der Meinung, es genügt (wenn überhaupt) die Fehlerbehandlung in den ios-Routinen oder gar erst in der Anwendung zu implementieren.

Aber nehmen wir mal an, wir bauen in Bella eine Prüfung ein, welche fehlerhafte Kommandosequenzen erkennt. Was dann? Ich muss dann zusätzlich eine Schnittstelle von Bella zu Regnatix schaffen, die auch ständig abgefragt wird, ob eine Fehler aufgetreten ist, um auf diese Fälle in der Anwendung zu reagieren. Ich denke schon das dieser Mechanismus einiges an Performance verbraucht und die Komplexität erhöht.

Nene, mit so einem Konzept kann ich mich nicht anfreunden: eine Fehlerprüfung auf unterer Ebene einzubauen ist in den meisten Fällen wie ein Hammer mit Lageerkennung, der mich mit Sprachausgabe darauf hinweist, wenn ich ihn falsch herum halte und der durch den dafür benötigten Akku ein paar Kilo mehr wiegt. Brauche ich nicht sowas, da nehme ich lieber den ganz einfach aus zwei Teilen bestehenden Hammer.

Wo ich dir aber recht gebe sind sicherheitskritische Systeme, also Steuerfunktionen in Maschinen, Elektronik in Fahrzeugen oder Sprengköpfe für Atombomben oder Herzschrittmache. Aber bei einem K1000-Replik oder einem Hive kann man da durchaus ein paar Gänge runterschalten. Die Wahrheit liegt halt wieder irgendwo zwischen den Extremen, was ich ja auch so zum Ausdruck gebracht haben, hab ja nicht geschrieben, dass man prinzipiell nicht an der Basis testen soll.

Vielleicht noch ein Hinweis von Charles Moore dazu:

"Halten Sie es einfach. Wenn sie mit einer Anwendung zu tun haben, wenn sie ein Teil des Designteams sind, versuchen Sie, die anderen Leute auch davon zu überzeugen, es einfach zu halten. Greifen sie nicht zu weit vor. Lösen Sie keine Probleme, von denen Sie glauben, dass sie in Zukunft auftreten können. Lösen sie die Probleme, die Sie jetzt haben. Vorrausschauen ist sehr ineffizient. Sie könne sich zehn Sachen vorstellen, die passieren können, von denen nur eine eintreten wird. Also haben Sie viel Aufwand umsonst getrieben."

Stammt aus dem Buch "Visionäre der Programmierung - Die Sprachen und ihre Schöpfer": http://www.amazon.de/Vision%C3%A4re-Pro ... =8-1-spell