Exceptions gehen zwischen den Threads verloren?

[p80286]

hallo zusammen.

Ich versuche mich z.Zt an einer Oberfläche für SQL-DBs. Solange es keine Fehler in der SQL-Source gibt läuft alles gut. Sobald dann ein Tippfehler oä auftaucht wird es unangenehm, weil die entsprechende Fehlermeldung teilweise verschluckt wird.

Delphi-Quellcode:

  ADOQuery1.close;
  ADOQuery1.SQL.Text:=QueryText.Text;
  try
    ADOQuery1.open;
  except
    on E: Eoleexception do
    begin
      { show all errors!}
//      ShowMessage(GetADOErrorString(ADOConnection1));
//      E.Message:=GetADOErrorString(ADOConnection1);
      raise exception.create(GetADOErrorString(ADOConnection1));
    end;
  end;

Mit

Delphi-Quellcode:

ShowMessage

wird die Fehlermeldung manchmal unvollständig angezeigt,
mit

Delphi-Quellcode:

E.Message

und

Delphi-Quellcode:

raise Exception

wird die Fehlermeldung in den meisten Fällen verschluckt.
U.U muß ich hinzufügen, daß Abfrage und Auslesen der Daten jeweils in einem eigenen Thread laufen.

Wie mache ich es richtig, daß der Benutzer über Fehler benachrichtigt wird?

Gruß
K-H

[Olli73]

Was genau läuft denn jetzt in welchem Thread?

Wenn du aus einem Thread heraus etwas anzeigen willst, musst du Synchronize() (o.ä.) benutzen.

Ansonsten hoffe ich mal, dass du nicht aus dem Thread heraus auf ADO-Komponenten auf dem Formular zugreifst.

[nahpets]

Fehler bei der Nutzung der ADO-Komponenten fange ich immer so in der Art ab:

Delphi-Quellcode:

    try
      Con.Connected := true;
      qry.SQL.Text := 'select * from Tabelle';
      qry.Open;
    Except
      on e : EAdoError do begin
        slError := TStringList.Create;
        slError.Add(e.Message);
        if con.Errors.Count > 0 then begin
          for i := 0 to con.Errors.Count - 1 do begin
            slError.Add('Number: ' + IntToStr(con.Errors.Item[i].Number));
            slError.Add('NativeError: ' + IntToStr(con.Errors.Item[i].NativeError));
            slError.Add('Description: ' + con.Errors.Item[i].Description);
            slError.Add('Source: ' + con.Errors.Item[i].Source);
            slError.Add('HelpFile: ' + con.Errors.Item[i].HelpFile);
            slError.Add('SQLState: ' + con.Errors.Item[i].SQLState);
          end;
          MessageDlg(slError.Text,mtError, [mbOk],0);
        end else begin
          MessageDlg(e.Message + #13#13 + qry.SQL.Text, mtError, [mbOk], 0);
        end;
        slError.Free;
      end;
      on e : Exception do begin
        MessageDlg(e.Message + #13#13 + qry.SQL.Text, mtError, [mbOk], 0);
      end;

Informationsverluste sind mir da bisher nicht aufgefallen.
(Die Aussagefähigkeit dieser Meldungen ist allerdings auch nicht immer unbedingt prickelnd ;-))

[p80286]

@nahpets
auf den ersten Blick das sieht meiner Procedure recht ähnlich:

Delphi-Quellcode:

function GetADOErrorstring(conn:TADOConnection):string; { nur die ADO-Errors!}
var
  iError : Integer;
  sError : string;
begin
  if conn.Errors.Count>0 then begin
    sError:=format('ADO-Error(s): %d',[conn.Errors.Count])+CRLF+CRLF;
    for iError := 0 to conn.Errors.Count - 1 do begin
      {-- ADO Errors:   }
      sError:=sError+Format('Error-No.: 0x%x',[conn.Errors[iError].Number])+CRLF;
      sError:=sError+Format('%s; (SQLState: %s)',[conn.Errors[iError].Description, conn.Errors[iError].SQLState])+CRLF;
      sError:=sError+Format('Source: %s', [conn.Errors[iError].Source])+CRLF;
      sError:=sError+Format('NativeError: %d', [conn.Errors[iError].NativeError])+CRLF+CRLF;
    end;
    result:=serror;
  end;
end;{-- GetADOErrorstring -------------------------------------------}

ich schau es mir mal näher an.

Zitat:

Zitat von Olli73 (Beitrag 1325015)

Was genau läuft denn jetzt in welchem Thread?

die nackte Abfrage in einem, die Datenausgabe im zweiten und dann gibt es noch den Hauptthread der leben vortäuscht.

Zitat:

Zitat von Olli73 (Beitrag 1325015)

Wenn du aus einem Thread heraus etwas anzeigen willst, musst du Synchronize() (o.ä.) benutzen.

Auch bei ShowMessage bzw. Exceptions? ich hab im Hinterkopf, das da automatisch was eigenes für erzeugt wird?

Zitat:

Zitat von Olli73 (Beitrag 1325015)

Ansonsten hoffe ich mal, dass du nicht aus dem Thread heraus auf ADO-Komponenten auf dem Formular zugreifst.

wenn Du unter Formular das Hauptformular verstehst (und nicht das DM) dann nein.



Gruß
K-H

[Olli73]

Zitat:

Zitat von p80286 (Beitrag 1325037)

Auch bei ShowMessage bzw. Exceptions? ich hab im Hinterkopf, das da automatisch was eigenes für erzeugt wird?

Also wenn man dem hier Glauben schenkt, dann ist nur Windows.MessageBox() (mit owner=nil !) threadsafe.

Zitat:

Zitat von p80286 (Beitrag 1325037)

wenn Du unter Formular das Hauptformular verstehst (und nicht das DM) dann nein.

Wenn du auf das Datenmodul bzw. dessen Komponenten nur aus dem Thread zugreifst, sollte das OK sein. Hast du aber z.B. an der gleichen ADO-Connection noch eine Query und daran z.B. datensensitive Controls angebunden (oder greifst sonstwie aus dem Mainthread darauf zu), hast du ein Problem.

[p80286]

Ok das mit der Messagebox scheint ja Hand und Fuß zu haben, versuch macht kluch. Aber was ist mit den Exceptions? ich meine mich zu erinnern, das eine Exception die Möglichkeit ist, ohne auf irgendetwas Rücksicht nehmen zu müssen, den Benutzer zu informieren. Gut ist etwas platt formuliert, aber von der Tendenz her richtig?


Datensensitive controls? Ich gehöre zu den wenigen, die die meiden wie der Teufel das Weihwasser. Alleine wenn du mal die Ausgabe irgendwohin umleiten mußt, ist der Aufwand viel zu groß, das dann zusammen zu stricken.

Gruß
K-H

[Olli73]

Zitat:

Zitat von p80286 (Beitrag 1325040)

Ok das mit der Messagebox scheint ja Hand und Fuß zu haben, versuch macht kluch. Aber was ist mit den Exceptions? ich meine mich zu erinnern, das eine Exception die Möglichkeit ist, ohne auf irgendetwas Rücksicht nehmen zu müssen, den Benutzer zu informieren. Gut ist etwas platt formuliert, aber von der Tendenz her richtig?

Nicht in Threads: http://edn.embarcadero.com/article/10452

Zitat:

Zitat von p80286 (Beitrag 1325040)

Datensensitive controls? Ich gehöre zu den wenigen, die die meiden wie der Teufel das Weihwasser. Alleine wenn du mal die Ausgabe irgendwohin umleiten mußt, ist der Aufwand viel zu groß, das dann zusammen zu stricken.

Auch wenn du da selber (aus dem Hauptthread) drauf zugreifst!

[himitsu]

Synchronize und Co. kopieren die Exception und lösen sie im aufrufenden Thread neu aus.

TThread.Execute tut das nicht. Dort ist man selbst verplichtet in OnTerminate, DoTerminate oder nach Beendigung des Threads das Property FatalException zu prüfen.
Hatte das mal bei Borland/Codegear reportet, aber sie hatten wohl keine Lust diese Funktionialität direkt einzubauen (abschaltbar), so daß es keiner vergessen kann.

Kann sein, daß es "früher", in uralten Delphis, nur innerhalb OnTerminate/DoTerminate auslesbar/verwendbar war und danach die Exception sofort freigegeben wurde.
In neueren Delphis wird die Exception via AcquireExceptionObject abgetrennt und bis zum Free ausgehoben.

[p80286]

Hallo zusammen,
erst einmal vielen Dank für die Hilfe!
Nachdem ich zunächst die "Messageboxlösung" ausprobiert habe:

Delphi-Quellcode:

...
msg:=GetADOErrorString(ADOConnection1);
Messagebox(0,pAnsichar(msg),'ADO-DB Error',MB_OK);

kann ich davon nur abraten, da auch dort manchmal ein Sprung ins Nirwana erfolgt.

Ich hab jetzt den Vorschlag von EMBa eingesetzt und es scheint zu funktionieren.
Wobei so richtig verstanden hab ich es nicht:

Delphi-Quellcode:

 // Cancel the mouse capture  ??
  if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0); {--- wofür soll das gut sein?}
  // Now actually show the exception
  if FException is Exception then {----- warum diese Unterscheidung?}
    Application.ShowException(FException)
  else 
    SysUtils.ShowException(FException, nil);

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1325088)

Wobei so richtig verstanden hab ich es nicht:

Delphi-Quellcode:

 // Cancel the mouse capture  ??
  if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0); {--- wofür soll das gut sein?}
  // Now actually show the exception
  if FException is Exception then {----- warum diese Unterscheidung?}
    Application.ShowException(FException)
  else 
    SysUtils.ShowException(FException, nil);

Das

Delphi-Quellcode:

WM_CANCELMODE

sorgt nur dafür, daß das nachfolgende Fenster auch auf Mausclicks reagieren kann. Es könnte ja sein, daß sich gerade ein anderes Fenster die Maus gekrallt hat. In dem Fall würde zwar die Exception-Meldung angezeigt, der Anwender könnte diese aber nicht mit der Maus wegclicken.

Was die Abfrage danach betrifft: Die Zuweisung nach

Delphi-Quellcode:

FException

erfolgt durch einen Hard-Cast von

Delphi-Quellcode:

ExceptObject

. Man kann also nicht sicher sein, daß wirklich eine

Delphi-Quellcode:

Exception

-Instanz drin steckt. Genau dies wird durch die (auf den ersten Blick unsinnige) Abfrage abgefangen.

Bonus-Wissen: Man kann nicht nur Exceptions raisen, sondern jede Klasseninstanz!

Delphi-Quellcode:

raise TButton.Create(nil);

Was auch immer man damit bezwecken will.