Die Ariane 5 ist abgestürzt, weil das System nicht mit einer unerwarteten Ausnahme eines von der Ariane 4 übernommenen Subsystems zurechtkam. Die Ausnahme selber wiederum wurde geworfen, weil bei der Konvertierung einer 64-Bit-Gleitkommazahl zu 16-Bit-Integer ein Overflow auftrat (bei der Ariane 5 kamen größere Werte vor als bei Ariane 4). Das werfende Subsystem lief zu diesem Zeitpunkt bereits leer.RustySpoon hat geschrieben:Ariane 5 ist abgestürzt weil eine Pfeife bei der ESA aus Performance-Gründen das Exception-Handling von Ada deaktiviert hat und der Code kopflos von Ariane 4 übernommen wurde.
Natürlich ist das eine Verkettung mehrerer unglücklicher Fehlentscheidungen, aber des Pudels Kern ist: Ausnahmen sind für kritische Fehler da, bei denen unter keinen Umständen fortgefahren werden kann. Und das sind Rechenfehler eben oft nicht. Das ist im IEEE 754-Standard berücksichtigt, indem dem Programmierer die freie Wahl gelassen wird, wann er Fehler als kritisch einstuft (Traps benutzen möchte) oder als unkritisch (bei FP-Flags und NaN, Flush-to-Zero, Flush-to-Infinity bleiben möchte). Java nimmt dem Programmierer diese Wahl und deklariert jeden noch so belanglosen Rechenfehler zu einer Ausnahme, die sofort alles abbricht und den Fehler hochdirigiert. Das ist schlicht und einfach unproduktiv und die Resultate sind alles andere als der gut wartbare Java-Text, den Leute aus Vorlesungen kennen.
„Without Traps nor Flags, Java’s floating-point is Dangerous.“ (How Java’s Floating-Point Hurts Everyone Everywhere) (Auch einen Blick wert: Wie Strömungsberechnungen in die Hose gehen, wenn man komplexe Zahlen benutzt. Und das ist genau die Art Anwendung, über die wir hier reden. Java ist und bleibt für wissenschaftliche und echtzeitkritische Anwendungen einfach eine der schlechtesten Wahlen.)
Tust du aber. Mein Text wird nach strengsten Richtlinien geschrieben, statisch analysiert und endlos getestet – aus dem Kopf fällt mir absolut keine Stelle ein, an der ich Leistung vor Sicherheit bevorzugt hätte. Alle meine schmutzigen Tricks sind unter fünf Abstraktionsschichten vergraben und gegen Missbrauch abgesichert. Aber falls du hier ein Gegenbeispiel findest, scheu dich nicht, es auszugraben ;)RustySpoon hat geschrieben:Ohne dir zu nahe treten zu wollen, aber ich kenn hier auch jemanden der gern mit solchen schmutzigen Performance-Hacks hantiert... ;)
Es soll auch einfach verifizierbare Sprachen geben, die IEEE 754 nicht mit Füßen treten.RustySpoon hat geschrieben:Aber auf Java möcht ich das auch nicht einfach sitzen lassen, die NASA arbeitet z.B. an einem Model-Checker für Java (http://javapathfinder.sourceforge.net/). Und Beweise in sicherheitskritischen Systemen sind immer so 'ne Sache. Eigentlich total wichtig und sinnvoll, aber praktisch normalerweise kaum sinnvoll durchführbar und da kommen Sprachen wie Java einem gegenüber C und Konsorten schon sehr entgegen.
