Problem: 'ungültige Gleitkommaoperation'

[DeddyH]

Ich würde ja noch 2 weitere Variablen einführen, nennen wir sie g und h, um bei der merkwürdigen Benennung zu bleiben. Das spart Wiederholungen und somit Berechnungen ein und lässt sich im Vorfeld leichter überprüfen.

Delphi-Quellcode:

var
  a, b, c, d, f, g, h: real;
begin
  a := strtofloat(edit1.text);
  b := strtofloat(edit2.text);
  c := strtofloat(edit3.text);
  g := b / a / 2;
  h := sqr(g) - c / a;
  if h < 0 then
    ShowMessage('Nicht lösbar')
  else
    begin
      d := g + sqrt(h);
      f := g - sqrt(h);
      Edit4.text := FloatToStr(d);
      Edit5.text := FloatToStr(f);
    end;
end;

[himitsu]

Zitat:

ob a=0

Ergibt einen Division-Durch-0-Fehler.

EDivByZero bei Integer-DIV
EZeroDivide bei Fließkomma-/

[Popov]

Zitat von Popov:

Alternativ kannst du die Rechnung in ein Try-Except-End Block packen. Gibt es einen Fehler, wird der Teil in Except ausgeführt.

Noch ein Nachtrag: soweit du es nicht irgendwo in der IDE abgeschaltet hast, bekommst du immer noch eine hässliche Fehlermeldung. Führst du später die Exe Anwendung direkt aus, kommt die Meldung evtl. nicht, d. h. du mußt selbst für eine Fehlermeldung sorgen.

[C0M3T]

Also DaddyH 's Quellcode kurz angepasst und ausprobiert.
Funktioniert nun wunderbar!
Vielen Dank an euch alle, für die schnelle Hilfe!

Delphi-Quellcode:

 var a,b,c,d,f,g,h:real;
begin
 a:=strtofloat(edit1.text);
 b:=strtofloat(edit2.text);
 c:=strtofloat(edit3.text);
 g:= b/a/2;
 h:= g*g-c/a;
 if h<0 then
 ShowMessage('Nicht Lösbar (Wurzel 0)')
 else
  begin
    d:= -g+sqrt(h);
    f:= -g-sqrt(h);
    Edit4.Text:=FloattoStr(d);
    Edit5.Text:=Floattostr(f);
  end;

[himitsu]

Zitat von C0M3T:

if h<0 then

kleiner Null

Zitat von C0M3T:

ShowMessage('Nicht Lösbar (Wurzel 0)')

gleich Null

[Bummi]

@himitsu
[OT]
bei dem vielen SQL den ich um die Ohren habe tut mir Null=0 weh
[/OT]

[C0M3T]

Habe ich schon angepasst 'Error: Wuzel(-x)'

[Popov]

Nur mal mein Senf zu den Bemühungen der letzten Stunden. Irgendwo oben habe ich geschrieben, dass ich von der Einstellung her keine Überraschungen mag, was bedeutet, dass ich zuerst prüfe ob eine Text-Datei vorhanden ist und welche Größe sie hat, bevor ich sie dann ich einem Try-Except Block öffne. Ich hab mal bei einigen meiner Projekte eine Überprüfung gemacht und festgestellt, dass fast ein drittel des Programms aus Überprüfungen besteht. Nun zu dem hier:

Delphi-Quellcode:

 var a,b,c,d,f,g,h:real;
begin
 a:=strtofloat(edit1.text);
 b:=strtofloat(edit2.text);
 c:=strtofloat(edit3.text);
 g:= b/a/2;
 h:= g*g-c/a;
 if h<0 then
 ShowMessage('Nicht Lösbar (Wurzel 0)')
 else
  begin
    d:= -g+sqrt(h);
    f:= -g-sqrt(h);
    Edit4.Text:=FloattoStr(d);
    Edit5.Text:=Floattostr(f);
  end;

Selbst ich mit meinem übertriebenem Kontrollsinn würde irgendwann es gut sein lassen. Eine Formel ist nun mal eine Formel. Eine vorherigen Überprüfung macht nur dann einen Sinn, wenn man eingreifen kann. Wenn ich a/b nehmen, kann ich vorher prüfen ob b gleich 0 ist. Aber was bringt mir das? Nichts. Ich kann die Fehlermeldung abfangen, vielleicht kann ich dem Nutzer auch sagen, dass b gleich 0 ist, wenn er b direkt eingeben kann, aber welchen Sinn macht es bei a/(b-c) vorher zu überprüfen ob b - c = 0 ergibt? Auf was ich hinaus will ist: irgendwann sollte man eine Kosten/Nutzen Rechnung machen. Und hier wäre die Frage: welchen Nutzen hat es eine Formel in seine Bestandteile zu zerlegen? Hat er Einfluss auf h wenn es kleiner 0 ist? Macht er eine 1 draus? Nein, er sagt nur, dass die Formel nicht funktioniert. Und das sagt ihm das System auch. Es hat also keinen Nutzen die Formel zu zerfleischen. Man sollte es irgendwann gut sein lassen. Aber das ist nur mein Senf.

Entweder man ist ein Kontrollfreak und überprüft vorher jeden Teil der Formel, was aber nur Sinn macht wenn man es beeinflussen kann, was hier nicht der Fall ist, oder mal läßt die Formel Formel sein.

Irgendwann sollte mal lernen mit der Fehlermeldung des Systems zu leben.

Delphi-Quellcode:

 var a,b,c,d,f:real;
begin
 a:=strtofloat(edit1.text);
 b:=strtofloat(edit2.text);
 c:=strtofloat(edit3.text);
 try
   d:=((b/a)/2)+sqrt(((b/a)/2)*((b/a)/2)-c/a);
   Edit4.Text:=FloatToStr(d);
 except
   Edit4.Text:='Fehler in der Berechnung 1';
 end;
 try
   f:=((b/a)/2)-sqrt(((b/a)/2)*((b/a)/2)-c/a);
   Edit5.Text:=FloatToStr(f);
 except
   Edit5.Text:='Fehler in der Berechnung 2';
   //...
 end;
end;

Nur mal als Info an C0M3T, eine Fehlermeldung kommt hier nur in der IDE. Beim fertigen Programm sieht man nur die Meldung in den Editfeldern.

[DeddyH]

Mal abgesehen davon, dass Du somit das DRY wieder im Code hast, müsstest Du dann aber auch wieder die Exception analysieren. Ich kann Dir aus Erfahrung sagen, dass nichts nerviger ist, als Fehlermeldungen der Art (Originalzitat):

Zitat:

Es ist ein Anwendungsfehler aufgetreten (EAccessViolation)

[Popov]

Ich hab zuerst die Fehlermeldung analysiert, hab sie dann wieder entfernt (Teile davon habe ich vergessen, siehe //... im zweiten Except Block), da ich mir überlegt habe welchen Nutzen es bringt zu wissen welcher Fehler vorkam. Dass ein Fehler in der Berechnung vorkommt steht im Editfeld.

Jetzt bitte nicht böse sein, aber was sagt dir die Meldung 'Nicht Lösbar (Wurzel 0)' , wenn du fünf Editfelder und ein Button auf dem Formular hast? Du fragst dich wahrscheinlich: was für eine Wurzel? Denn von einer Wurzel sehe ich auf dem Formular nichts. Für mich ist das Formular eine Blackbox. Ich gebe drei Zahlen ein und bekomme zwei Ergebnisse, wenn ich Ok klicke. Selbst wenn ich wüßte was für eine Formel dahinter steckt, ich kann es nicht beeinflussen, denn ich hab keinen direkten Einfluss auf h. Soll ich vorher einen Taschenrechner nehmen alles durchrechnen, damit ich fehlerfreie Eingaben machen? Wozu dann bitte das Programm?

Sinn würde es hier machen:

Delphi-Quellcode:

 var a,b,c:real;
begin
 a:=strtofloat(Edit1.text);
 b:=strtofloat(Edit2.text);
 if b = 0 then
 begin
   MessageDlg('Feld 2 enthält 0 (Division durch 0)', mtError, [mbOk], 0);
   Exit;
 end;
 c := a / b;
 Edit3.Text:=FloatToStr(c);
end;

Hier habe ich die Eingaben analysiert und sage dem Anwender wie er den Fehler vermeiden kann. Aber spätestens bei der Formel c := a / (b - 1) würde eine Division durch 0 dem Anwender nichts bringen. Die Formel ist Komplex, er hat keinen Einfluß drauf. Also lieber gleich ein allgemeines Error.

Es ist nicht verwerflich eine allgemeine Fehlermeldung auszugeben wenn sie dem Anwender sowieso keinen Sinn ergibt. Und hier macht es keinen Sinn. Die Formel ist zu komplex, er kann sie nicht anpassen.