Visual Basic Fehler "Division durch Null" ?

Mortiss · 10. September 2006

Hallo,

kann mir jemand sagen, wie ich eine Anwendung (in diesem Falle einen Taschenrechner) so fixen kann, dass wenn man durch 0 teilen will, die Anwendung nicht abstürzt?

Die Fehlermeldung lautet:

"Laufzeitfehler 11

Division durch Null"

thx im Voraus

Mortiss

Boron · 10. September 2006

AW: Visual Basic Fehler "Division durch Null" ??

Ist jetzt keine Basic Syntax:

Code:

if( b == 0 )
{
   // keine Division durchführen
}
else
{
   c = a / b;
}

Der einfachste Weg ist immer diesen Fall gesondert abzufangen.

Arnd · 10. September 2006

AW: Visual Basic Fehler "Division durch Null" ??

Es gibt auch noch so etwas wie "On Error Resume". Die korrekte Anwendung sollte in der Hilfe beschrieben sein.

Allerdings ist die obige Lösung ein deutlich besserer Programmierstil.

MfG

Arnd

arc_user · 11. September 2006

AW: Visual Basic Fehler "Division durch Null" ??

oder ->>

if(b) c = a / b;

:=))

Mortiss · 14. September 2006

AW: Visual Basic Fehler "Division durch Null" ??

Hallo,

erstmal danke für die Tipps, nur komme ich noch nicht weiter.

Wenn ich den Code wie oben angegeben eingebe, so kommt bei "division durch null" dann ein "Syntaxfehler".

Ich kenne mich so gut wie garnicht mit Visual Basic aus, muss das halt für die Schule lernen und nutze Visual Basic 6.0 (um das wegen der Kompatibilität zu klären.

wie kann ich folgenden Programmcode modifizieren, damit er einwandfrei funktioniert, und WO muss ich eingreifen?

Code:

'Wenn der erste Text eine Zahl ist und auch der zweite Text eine Zahl ist
If IsNumeric(Text1.Text) And IsNumeric(Text2.Text) Then
'Dann wird diese Rechenart überprüft und gerechnet
Select Case Combo1.ListIndex
Case 0: Label2.Caption = CSng(Text1.Text) + CSng(Text2.Text)
Case 1: Label2.Caption = CSng(Text1.Text) - CSng(Text2.Text)
Case 2: Label2.Caption = CSng(Text1.Text) * CSng(Text2.Text)
Case 3: Label2.Caption = CSng(Text1.Text) / CSng(Text2.Text)

End Select
Else


'ansonsten bekommt der Bediener einen Hinweis angezeigt
MsgBox "Bitte geben Sie Zahlen in beide Felder ein!"
    End If

Dieser Code berechnet eben die Zahlen aus Feld 1 und Feld 2, die man im Combo1.ListIndex ausrechnet. Gibt man jetzt das : Zeichen, und im Feld 2 die 0 ein, so stürzt die Anwendung ab

Da ich zuhause nur das "Ablaufmodell" von VisualBasic 6.0 installiert habe, bleibt mir die Hilfe verwehrt.

Könnt ihr mir das etwas genauer erklären? Ich kenne eben so gut wie keinen Befehl außer z.B. "If und Else"

Gruß
Mortiss

Arnd · 14. September 2006

http://www.vb-seminar.de/vb_32.htm

Alternativ

On Error Resume Next

Damit wird der Fehler einfach ignoriert.

Oder

Code:

Select Case Combo1.ListIndex
Case 0: Label2.Caption = CSng(Text1.Text) + CSng(Text2.Text)
Case 1: Label2.Caption = CSng(Text1.Text) - CSng(Text2.Text)
Case 2: Label2.Caption = CSng(Text1.Text) * CSng(Text2.Text)
Case 3: [COLOR="Red"]IF CSng( Text2.Text)[/COLOR] <> 0 [COLOR="red"]THEN[/COLOR] Label2.Caption = CSng(Text1.Text) / CSng(Text2.Text) [COLOR="red"]ENDIF[/COLOR]

End Select

Bitte nicht wörtlich abtippen, ich habe kein VB installiert kann es daher also nicht ausprobieren.

MfG

Arnd

XunnD · 15. September 2006

Obacht - sich bitte mit den mathematischen Grundregeln auseinander setzen. Das ist Mathematik.
Der Fehler "Division durch Null" ist schon EXTREMST AUSSAGEKRÄFTIG!!!

Du weißt, Du hast eine Division, Du weißt, wo Du Deine Division hast - warum prüfst Du dann nicht vorher Deinen Divisor, bevor Du dividierst, damit dort kein Fehler kommt und Du das somit abfangen könntest... Das ist pure Logik.
Arnd hat's schon erfasst.

Ansonsten gilt für mich: *brrrr*, BASIC

MagicAndre1981 · 15. September 2006

XunnD schrieb:
Ansonsten gilt für mich: *brrrr*, BASIC

gute Einstellung

Mortiss · 15. September 2006

XunnD schrieb:
Obacht - sich bitte mit den mathematischen Grundregeln auseinander setzen. Das ist Mathematik.
Der Fehler "Division durch Null" ist schon EXTREMST AUSSAGEKRÄFTIG!!!

Du weißt, Du hast eine Division, Du weißt, wo Du Deine Division hast - warum prüfst Du dann nicht vorher Deinen Divisor, bevor Du dividierst, damit dort kein Fehler kommt und Du das somit abfangen könntest... Das ist pure Logik.
Arnd hat's schon erfasst.

Ansonsten gilt für mich: *brrrr*, BASIC

sehr schön geschrieben - wirklich - sehr schön!

nur habe ich eben bislang so gut wie keine Erfahrung mit VB, und wie ich etwas "prüfe" weiss ich schon garnicht.

Außerdem - abgesehen davon, ist es meine Aufgabe, die mir die Lehrkraft gegeben hat, dass ich eine Lösung finde, dass das Programm bei Division durch null nicht abstürzt. - egal.

Also ist für mich - also für den, der die Frage bzw. das Problem hat - deine Aussage mindestens genauso aussagekräftig, wie die "Division durch Null"

Gruß
Mortiss

PS:

MagicAndre1981 schrieb:
gute Einstellung

dieser Beitrag hilft noch weniger

Update: Danke Arnd, nun läuft es

XunnD · 16. September 2006

On Error Resume Next hilft Dir nicht weiter - Du behebst damit den Fehler nicht, sondern verhinderst nur, dass das Programm damit beendet wird.
Toller Programmierer bist Du da!

Fehler-Ursache finden und beheben heißt Deine Lösung. Und das geht mit Mathematik besonders gut. Eben, indem man den Divisor prüft (genau das macht Arnd in seinem Sourcecode).

Dass man mit IF... THEN... eine Bedingung "erstellt" sollte man schon wissen.

Programmierung ist nicht: "Komponenten auf ein Formular zusammenklicken", was "Visual" BASIC gerne versprechen mag - und erst recht ist es nicht: "Code kopieren und hoffen, dass es klappt."

Nachtrag: "Division durch Null" - wenn Du beim Betrachten Deines Codes Deine Division (wo ja ein "Division durch Null" auftreten kann) nicht finden kannst, musst Du wohl blind sein (Du hast es auch noch selbst geschrieben).

"Division durch Null" sagt mir: es gibt einen Fehler, bei dem ein Wert durch den Wert 0 dividiert wird (Sprich: Divisor = 0) - einfacher gehts nun wirklich nicht...

Morgoth · 16. September 2006

Mit dieser simplen Abfrage ist es eigentlich nicht getan.

Es gibt nämlich auch Anwendungen, wo der Divisor sehr klein, aber eben nicht 0 wird, und trotzdem einen Überlauf produzieren kann.

Hier bieten Exceptions (Ausnahmen) bzw. das dazugehörige Handling eine Möglichkeit, diesen Fehler abzufangen, das Programm nicht abstürzen zu lassen und in einem bekanntem Zustand weiterarbeiten zu können. Laut Wikipedia hat Visual Basic ein Exception Handling.

Taschenrechner, also die Applikation worum es hier geht, haben so etwas auch. Führt mal die Berechnung (je nach Taschenrechner) 10*1^99 durch, der Taschenrechner wird einen Fehler anzeigen und trotzdem noch eingabebereit sein. Dies wird nicht durch zahlreiche IF/THEN/ELSE-Abfragen erreicht, sondern auf anderem Wege (macht die ALU/MAC automatisch, so einen Mechanismus müssten eigentlich moderne Prozessoren - also seit 30 Jahren - auch integriert haben).

Gruß
Morgoth

XunnD · 16. September 2006

@Morgoth: Du wirst mir jetzt aber nicht erzählen wollen, dass er das gewusst haben könnte???

Morgoth · 16. September 2006

Ich wollts nur mal erwähnt haben. Wenn schon auf ihm herumgehackt wird, dann bitte korrekt.

Gruß
Morgoth

XunnD · 16. September 2006

Ich bin ja der Meinung, dass, wenn eine Division durch Null-Exception getriggert wird (kommt dann ja vom Prozessor), die CPU ja schon auf 0 geprüft hat, denn berechnen kann sie es ja nicht - d.h. theoretisch müsste man dann - wenn die Exception trotz eines mathematischen Werts ungleich 0 geworfen würde - mit einer Abfrage à la IF...THEN... auf 0 auch weiter kommen...

Meinste nicht auch?

arc_user · 17. September 2006

ich kenne solche exception nur fuer fehlerhafte speicherzugriffe.(zb. lesen/schreiben 4byte von 0x00000003 ). selbst dies macht bei x86 riesigen aufwand und wird bei den meisten RISC
weggelassen eine div durch null muss man eigendlich im code abfangen.

Morgoth · 17. September 2006

XunnD schrieb:
Ich bin ja der Meinung, dass, wenn eine Division durch Null-Exception getriggert wird (kommt dann ja vom Prozessor), die CPU ja schon auf 0 geprüft hat

Die CPU wird nen Teufel tun und auf 0 überprüfen. Soll sie das bei jeder Division machen? Und was ist, wenn es eben keine Null ist, aber es doch einen Überlauf gibt?

Nee, das kostet viel zu viel Zeit, da wird lieber berechnet und wenn es dann einen Überlauf gibt wird eben ein Flag gesetzt/eine Exception ausgelöst.

Wie das bei Fließkommarithmetik geht weiß ich nicht, ich kann mich aber dunkel daran erinnern, dass schon der uralte 8085 so ein Flag hatte (zumindest bei Integer-Berechnungen, das Ding hat ja nur ne ALU), das bei Überlauf gesetzt wurde.

Wie schon gesagt, mit "auf 0 überprüfen" ist es eben nicht getan. Du kannst auch mit simpler Addition, Subtraktion oder Multiplikation einen Überlauf erzeugen.

Gruß
Morgoth

arc_user · 17. September 2006

dividieren und addieren kann man nicht vergleichen.
bei einem ueberlauf durch eine addition hat dies nur logische fehlfolgen, aber da eine division aus einem loop von registe-manipulationen besteht, wuerde es bei einer division
NULL zu einem endlos_loop kommen. kann schon sein, dass einige prozessoren darauf
reagieren koennen, aber normal muss dies durch zusaetzlichen aufwand in der hardware
erfolgen.

arc_user · 17. September 2006

@morgoth
fuer die ALU geht bei div NULL alles seinen geregelten gang, nur in der abarbeitung des programm wuerde die ALU fuer immer das selbe machen. bei moderneren prozessoren werden loops auch unabhaenig behandelt, da koennte es sein, dass eine programmierung eines loopcounters eine exception ausloesen koennte. was einen 8085 angeht wuerde ich sagen, dies funktioniert da anders. ein beispiel fuer einen solche funktionalitaet sind ARC-prozessoren.

Arnd · 19. September 2006

Jetzt möchte ich meinen Kommentar auch noch dazugeben :-).
Die Aussagen bzgl. ALU, CPU, etc. sind sicher alle korrekt. Allerdings sollte das eigentlich auf Assemblerebene oder bestenfalls noch C eine Rolle spielen.

Als Anwendungsprogrammierer und dann noch bei Basic würde ich das auf einer höheren Ebene betrachten wollen. Welche Flags da in der CPU/FPU gesetzt sind interessieren mich da weniger.

Einfache Fehler wie Divsion durch 0 sollte man per IF THEN abfangen. Das nicht alle Exceptions mit IFs abgefangen werden können ist korrekt. Und genau deswegen macht ein ON ERRROR (RESUME NEXT oder GOTO) Statement sehr viel Sinn. Damit werden dann die
unbekannten Fehler abgefangen.

Hilfreich für den Anwender und den Programmierer ist dann noch eine vernünftige Abfrage des aufgetreteten Fehlers und eine entsprechende Visualisierung gegenüber dem Anwender. D.h. bei Div durch 0 oder 2*10^99, ... z.B. die Ausgabe von ERROR im Display des Taschenrechners.

MfG

Arnd

XunnD · 19. September 2006

Naja, die Daten-0 (also der Divisor) muss von der CPU (bzw. der ALU) sowieso "angefasst" werden - und da kann ja wohl ein CMP-ähnlicher Befehl nicht schaden.

Weiß jemand über die genaue Implementierung Bescheid?
Sprich: was läuft EXAKT ab, wenn eine Division in der ALU durchgeführt werden ?

Visual Basic Fehler "Division durch Null" ?

Banned

Commander

Lieutenant

Cadet 4th Year

Banned

Lieutenant

Lieutenant

Admiral

Banned

Lieutenant

Captain

Lieutenant

Captain

Lieutenant

Cadet 4th Year

Captain

Cadet 4th Year

Cadet 4th Year

Lieutenant

Lieutenant

Ähnliche Themen