Warum keine Exception bei Division durch 0

[Jelly]

OK, ich glaub das Problem ist doch nicht so tragisch.

Delphi-Quellcode:

procedure TForm1.cmd1Click(Sender: TObject);
var
 a, b, c, d  : double ;
begin
     a := 0 ;
     b := 0 ;
     c := a/b ;   // ->  hier krieg ich ne Exception ;
     d := 0/0 ;   // ->  und hier nicht
     showmessage (floatToStr(c)) ;
end;

0/0 akzeptiert er also, a/b zum Glück nicht. Da in meinem Programm natürlich nirgends direkt 0/0 steht, sondern ich eben nur mit Variablen arbeit, müsst ich in der Simulation natürlich eine Exception kriegen. Da dies aber nicht der Fall ist, muss ich den Fehler wohl sonstwo suchen.

Gruß,


EDIT: Danke noch an alle, und Luckies Erklärung scheint mir sehr einleuchtend..

[Luckie]

d := 0/0 wird wieder wegoptimiert. Guck mal, ob ein blauer Punkt vor der Zeile am Rand ist.

[Jelly]

Zitat von Luckie:

Guck mal, ob ein blauer Punkt vor der Zeile am Rand ist.

Nöö, ist keiner. Womit ich jetzt auchverstanden hätt, was diese blaue Punkte überhaupt bedeuten

[woki]

Hi,

also nochmal zusammenfassend, damit auch flüchtige zukünftige Leser das richtig verstehen:

Selbstverständlich löst Delphi bei Division durch Null immer auch bei allen Gleitkommazahlen einen Laufzeitfehler (EZeroDivide) aus.
Da eine Division durch Null mathematisch gar nicht definiert ist, was sollte Delphi denn da auch für ein Ergebnis zurückliefern.
Aber Voraussetzung ist natürlich, daß der Code überhaupt ausgeführt wird, und nicht z.B. vom Optimizer wegoptimiert wurde. Von daher ist es sehr sinnvoll, beim Debuggen den Optimizer abzuschalten,
und wenn man nicht debugged beim Entwickeln den Debugger auszuschalten, das kostet nämlich eventuell sehr viel Rechenzeit. Ein Hinweis noch: Wenn einem die IDE zu langsam wird, gibt es noch einige Dinge, die man abschalten kann, wenn man sie gerade nicht braucht.

Grüße
Woki

[Hansa]

Zitat von Luckie:

Dein Beispiel-Code wird gar nicht ausgeführt. Der Compiler ist ja nicht blöd, er sieht, dass du die Varaible nie benutzt und optimiert sie weg.

Luckie, das war echt gut. Ist mir gar nicht aufgefallen. Da sieht man mal wieder, daß man sich auch zu Tode optimieren kann.

[Robert Rossmair]

Zitat von woki:

Selbstverständlich löst Delphi bei Division durch Null immer auch bei allen Gleitkommazahlen einen Laufzeitfehler (EZeroDivide) aus.

Falsch. Weder löst Delphi die Exception aus, noch wird diese immer ausgelöst:
- Fließkommaarithmetik wird von der Fließkommaeinheit des Prozessors (der FPU) ausgeführt, die den IEEE-Standard 754 implementiert (http://grouper.ieee.org/groups/754/). Es ist auch die FPU, die ggf. eine Exception wirft. Delphi verpackt diese nur ansprechend.
- Fließkomma-Exceptions lassen sich in der FPU ausmaskieren, die Unit Jcl8087 stellt dazu Funktionen zur Verfügung. Ist eine Exception maskiert, wird statt dessen ein Flag im Statuswort der FPU gesetzt (Jcl8087: GetPending8087Exceptions) und evtl. ein spezieller Wert zurückgeliefert. Siehe dazu auch die Erläuterungen zum Typ JclMath.TFloatingPointClass in der Online Hilfe der JCL.
Die Exception bleibt latent, bis entweder die Maskierung aufgehoben wird, oder die latenten Exceptions gelöscht werden (Jcl8087: ClearPending8087Exceptions). Hebt man die Maskierung auf, ohne die Löschung vorzunehmen, dann werden die latenten Exceptions ausgelöst - evtl. an einer Stelle im Code, die nichts mit der Ursache zu tun hat.

Zitat von woki:

Da eine Division durch Null mathematisch gar nicht definiert ist, was sollte Delphi denn da auch für ein Ergebnis zurückliefern.

+/-Unendlich, falls Zähler <> 0, oder ein NaN (not a number), falls Zähler = 0.

Zitat von woki:

Aber Voraussetzung ist natürlich, daß der Code überhaupt ausgeführt wird, und nicht z.B. vom Optimizer wegoptimiert wurde.

Dass im gegebenen Fall irgendwelcher Beispielcode nicht kompiliert wird, ist ganz unerheblich. Es gäbe in keinem Fall eine Exception, weil zur Laufzeit(!) keine Division ausgeführt wird. Ausdrücke, die ausschließlich Konstanten enthalten, rechnet nämlich der Compiler aus.

- Robert