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