V 1.9 / Programmabstürze ohne Fehlermeldung ...

[Krause]

Programmabsturz nach Division durch Null ...

Niemand ist absolut fehlerfrei, um so mehr ist man in komplexen Programmabschnitten auf eine zutreffende Fehlermeldung angewiesen. Version 1.9 verabschiedet sich absolut ohne Fehlermeldung nach (hier vereinfacht dargestellt)

Code: Alles auswählen

A:=1; B:=0
C:=Round(A/B, 8)

MfG
Joachim

[Jan]

Schau doch mal nach, ob es ein XPPFATAL.LOG gibt. Da sollten nähere Infos drin stehen zum Fehlergrund.

Jan

[Krause]

Hi Jan,

- keine Fehlermeldung
- keine XPPFATAL.LOG.

Das Unberechenbare daran ist die Tatsache, dass am Anfang einer Test-Main der Wert 0,00000000 zurückgegeben wird. Die Ursache habe ich noch nicht herausgefunden. Zwischendurch habe ich einen DLL-Aufruf, dort wird aber kein Error - Codeblock gesetzt.

MfG
Joachim

[Martin Altmann]

Hallo Joachim,
Ursache ist Division durch 0!
Dies wird (wenn ich mich recht erinnere) nicht in der Standard-Errorsys abgefangen - da solltest/mußt Du entsprechend das ganze modifizieren...

Viele Grüße,
Martin

[Krause]

Hi Martin,

dass habe ich dann auch gemacht (Wertebereichsüberprüfung vor Codeausführung) in einer eigenen internen PrivatRound() - Funktion. Irritierend ist jedoch der Rückgabewert "0,00000000" am Anfang der Test-Main.

Mit freundlichen Grüßen
Joachim

[Manfred]

Hi Martin,

in der Erorsys wird das mit einem Error 0 bearbeitet. Scheint also doch abgefangen zu werden.

[Rolf Ramacher]

Hi,

zeig uns doch mal deinen kompletten Code. oder fang mit einer If-Abfrage den Devisor ab.

[Martin Altmann]

Hallo Manfred,
dann ist ja gut - ich kann mich nur noch dunkel an diverse Postings zu diesem Problem vor einiger Zeit in den Alaska-Newsgroups erinnern...

Viele Grüße,
Martin

[brandelh]

Hallo Manfred,
dann ist ja gut - ich kann mich nur noch dunkel an diverse Postings zu diesem Problem vor einiger Zeit in den Alaska-Newsgroups erinnern...
Viele Grüße,
Martin

Xbase++ und Clipper liefern zwar bei nWert / 0 einen Wert zurück, (meist ist 0 ja auch nicht genau 0 ) aber das hilft nur insoweit, dass das Programm nicht abstürzt (bzw. nicht abstürzen dürfte ).

DAS Problem besteht aber weiterhin insoweit, dass das Ergebnis nicht richtig ist, da eine Division durch 0 nicht erlaubt ist. Je nach Anwendung kann das gravierende Folgen haben !

Der Compiler kann das nicht abfangen, das muss der Entwickler tun.
In allen Situation in denen eine Division durch 0 möglich ist, muss man diese durch Vorprüfung verhindern

[Martin Altmann]

Hubert,
ich habe damit ja nicht gemeint, dass eine Division durch 0 OK ist!
Früher gab es einen Laufzeitfehler, der genau das besagte.
Und dann gab es das nicht mehr, sondern nur einen SPT, ohne Log.

Viele Grüße,
Martin

[brandelh]

XppFatal.LOG nach normalem Fehler und es wird ein STACK Fehler angeführt ?

meist ist dann ein Fehler in der angepaßten XppError.PRG die Ursache:

Ein normaler Fehler tritt auf,
XppError() will ihn abfangen, aber der Code ist auch Fehlerhaft ...
XppError() wird nun aufgerufen um diesen Fehler in der Fehlerroutine abzufangen.
Falls dabei wieder die fehlerhafte Stelle im Errorhandler aufgerufen wird, läuft es in eine Endlosschleife bis der STACK voll ist.

Ähnlich verhält es sich mit einer rekursiven Funktion die zu tief verschachtelt ist oder gar keine gültige Endebedingung hat.
In einem Beispiel war nach etwa 3100 Aufrufen die XppFatal.LOG erreicht.

Ein Problem aus DOS Tagen tritt heute nicht mehr auf:

alle Dateihandles sind verbraucht, aber die XPPERROR.LOG soll noch geschrieben werden ... das führte zu einem Fehler und die Recursion in den Programmabsturz war da. Unter Xbase++ wird es wohl immer einen Handle geben

[Krause]

Hi

muss mich nun doch selbst korrigieren, innerhalb einer DLL - Funktion konnte es unter bestimmten Bedingungen vorkommen (Fehlerhafter Code),
das ein Error - Codeblock

Code: Alles auswählen

{ |e| Break(e)} 

"stehen geblieben" war, bleibt also nur noch die Frage offen, warum

Code: Alles auswählen

LOCAL A:=1, B:=0
? A / B                    ---> 0 
? Round( A / B , 8)        ---> 0,00000000 

ergibt und keinen Laufzeitfehler bzw. was denn Sinnvoller währe ...

Mit freundlichen Grüßen
Joachim

[brandelh]

ergibt und keinen Laufzeitfehler bzw. was denn Sinnvoller währe ...

zu 1. in Clipper war es auch schon so
zu 2. ich habe keine Ahnung was sinnvoller ist.

Auf jeden Fall muss das Programm - und damit WIR - sicher stellen, dass es nicht vorkommen kann.