🚀 go-pugleaf

Dietmar Kuehl wrote:
Hi,

> : Dietmar Kuehl wrote:
> Ich hoffe, dass ich nie in die Verlegenheit komme, in ein Flugzeug zu
> steigen, dessen Autopilot von Dir oder jemandem mit einer aehnlichen
> Einstellung programiert wurde:  Das Programm mag zwar toll sein und
> z.B. automatisch einen Rundflug fliegen, aber wenn beim Aufruf der
> Rundflugprozedur zuwenig Speicher da ist, entschliesst sich das
> Programm NICHT, einfach weiterzufliegen (eben ohne Rundflug), sondern
> schaltet einfach mal ab.

Du hast natuerlich recht, dass im Flugzeug-Fall die Fehlerbehandlung
nicht in "assertion failed at..." und anschliessendem Absturz 
bestehen darf. assert() sollte deshalb
nur bei echten Programmfehlern verwendet werden, um zu verhindern, dass
man diese durch Toleranz ewig mitschleppt und das undefinierte Verhalten
dann an anderer Stelle potenziert zuschlaegt. 

> Ein solches Verhalten mag im wissenschaftlichen Bereich (die GMD ist ja
> kein industrielles Unternehmen) angemessen sein (die Tests steigen halt
> mit 'ner Fehlermeldung aus), sind aber sonst in der Regel
> katastrophal:  Wenn kein Speicher da ist, muss man allzu oft dafuer
> sorgen, dass es trotzdem weitergeht. Exceptions sind genau dafuer gut,

Meine Karriere bei der GMD ist noch relativ kurz, vorher war ich
in Software-Unternehmen. Genau dort habe ich auch die Meinung
kultiviert, dass programmierte Toleranz gegebenueber Programmierfehlern 
nur zu laxer Qualitaetssicherung und schwerer Auffindbarkeit von
Fehlerursachen fuehrt

Im Uebrigen gibt's ja noch -D_NDEBUG, um alle assert()-Anweisungen
zu disablen.

Dass Speicheralloziierung fehlschlaegt, das wissen wir alle ;-), liegt
hauptsaechlich daran, dass vorher der Heap korrumpiert wurde. Und
solche Fehler sollten nicht verschleppt werden.
Wenn der Heap erst einmal zerstoert ist, gibt's i.d.R. keinen Speicher
mehr, und dann geht es eben nicht weiter. Sicherungssysteme dieser
Art muessen ausserhalb des Programms liegen.
Und sollte der Heap in Ordnung sein und der Speicherplatz nur voll:
Ich moechte natuerlich auch kein Flugzeug betreten, in dem mit Haupt-
speicher gegeizt wurde.

> dass man anstatt einem 'assert()' eine solche wirft: Wenn sie nicht
> irgendwo gefangen wird, dann ist halt 'terminate()' faellig. Aber es
> gibt Situationen, und zwar ausreichend viele und ich denke sogar die
> Mehrzahl, in denen man eben schlimmstenfalls darauf verzichten kann,
> einen bestimmten Teil des Programms auszufuehren.
> Als Beispiel kann man sich einen interaktiven fuer sonstwas (Text,
> Grafik, Audio,...) vorstellen, dass eine Modification-History
> mitfuehrt. Wenn ein neues Element eingefuegt wird und kein Platz mehr
> da ist (d.h. der entsprechende Konstruktor wirft eine Exception), dann
> kann man ja die Modification-History etwas aufraeumen oder Teile
> auslagern.

Uebrigens habe ich auch sehr lange Zeit eine "tolerante" Fehler-
behandlung verteidigt, mit recht aehnlichen Argumenten. Ein weit
verbreiteter Irrtum ist IMHO, dass Programmierfehler unerwartete
Zustaende eines Programms seien. Es gibt natuerlich definierte
Zustaende, die ein Programmierer nur nicht bedacht hat, die aber
im Rahmen seines Designs sichtbar sind. Diese Dinge sind meiner
Meinung nach zu tolerieren. Andere, wie etwa Zerstoerung des
Heaps, sind reine Programmschwaechen, und die sollten sofort
waehrend des Tests angezeigt werden.

Schliesslich finde ich, dass bei der Programmierung von
Steuerungssystemen von Flugzeugen und eine ueberzeugendere
Fehlertoleranz und -kompensation her muss als "der Programmierer
hat uns versichert, alle Exceptions abgefangen und behandelt
zu haben". Ich wuerde mal - statistisch fragwuerdig und
voellig unwissenschaftlich - behaupten, dass bei einem solchen System
10% Steuerung und 90% Kontrolle der Steuerung und Kontrolle der
Kontrolle der Steuerung sind.

> ... was nicht geht (in meinem "Konstruktor"-Artikel habe ich eine
> Sequenz 'this->~T(); new(this) T()' verwendet):  'this' (in einer
> Methode von 'T')  ist deklariert als 'this *const'. In einer 'const'
> Methode ist es als 'this const *const' deklariert. Die Deklarationen
> von 'this' sind natuerlich implizit. Man konnte irgendwann (CFront-1.0
> oder so) zu 'this' zuweisen. Das geht schon lange nicht mehr.
Da hast Du sicher recht, habe da nicht sehr detailgetreu geschrieben...

Mein Hauptkritikpunkt an Exceptions war ja auch aesthetischer
Natur ;-) Saehen sie besser aus, wuerde ich assert() auch nicht
mehr benutzen.
-- 
*	Greetinx from Watson (sayegh@fokus.gmd.de)
	http://www.fokus.gmd.de/ovma/employees/sayegh/entry.html
	signal(SIGSEGV,SIG_IGN);