EIdSocketError #10053 In Webbroker

[himitsu]

Natürlich wäre es sinnvoll, wenn nicht unnötig viele Exceptions auftreten.
Pervers: in einigen Komponenten/Progammen kamen Leute auf die geniale Idee Exceptions zur Ablaufsteuerung zu benutzen.

* In Delphi selber kann man leider nur nach Exception-Klasse und dauerhaft das Verhalten anpassen.
Also z.B. dass Delphi bei "dieser" Exception nicht mehr anhält / sie nicht mehr zeigt.

* Es gibt auch Plugins/Extensions, die das besser machen.
Parnassus Parallel Debugger (siehe GetIt) ... dort kann man auch auf den Message-Text filtern.



Schön wäre es auch, wenn man noch sagen könnte "nur für diese Session ignorieren", bzw. "nur im aktuellen Projekt",
aber so ein Feature braucht noch 20 Jahre, bis jemand es schafft das einzubauen.

[jaenicke]

Zitat von bcvs:

Ich gehe mal davon aus, dass die Exception immer auftritt.

Vielleicht liegt es am Virenscanner?

Zitat von himitsu:

Pervers: in einigen Komponenten/Progammen kamen Leute auf die geniale Idee Exceptions zur Ablaufsteuerung zu benutzen.

Das habe ich auch gemacht, aber nur mit eigenen Exceptions, die man einfach ignorieren kann.

Zitat von himitsu:

Schön wäre es auch, wenn man noch sagen könnte "nur für diese Session ignorieren", bzw. "nur im aktuellen Projekt",
aber so ein Feature braucht noch 20 Jahre, bis jemand es schafft das einzubauen.

Du solltest einmal GExperts installieren.

[Delphi.Narium]

Die Fehlermeldung heißt eigentlich nur, dass die Gegenseite die Verbindung abgebrochen hat.

Innerhalb von Indy kannst Du das Problem nicht beheben, da müssten wir mal den Quelltext sehen, der für den Aufruf, die Verbindung, ... zuständig ist, sowas wie sContent := http.get('www.irgendwas.com'); Was ich (sinngemäß und hier nur hingedaddelt) grundsätzlich mache, um Folgefehler zu reduzieren:

Delphi-Quellcode:

iError := 0;
repeat
  try  
    http.Get('ne url',EinStream);
    // Daten verarbeiten ...
    break;
  except
    on e : EIdSocketError  do begin
      iError := iError + 1;
      http.Disconnect(True);
      http.IOHandler.InputBuffer.Clear;
      continue;
    end;
    // weitere Fehler abfangen
    // ...
    // und zum Schluss dann noch die "Reste"
    on e : Exception do begin
      iError := iError + 1;
       // sinnvolle Fehlerbehandlung, Fehler ggfls. protokollieren.
       // Fehlerabhängig ggfls. per break aus der Schleife raus,
       // z. B. bei ResponseCode 403 oder 404
       // oder ResponseCodes aus dem 300er-Bereich.
    end;
  end;
  // Aufräumen!!! - ohne dies kann bei einigen Fehler "irgendwas" übrigbleiben,
  // was eine weitere, sinnvolle Arbeit des Programmes unmöglich macht.
  // Die Interna kenn' ich nicht, so dass ich nicht weiß, warum es ohne die
  // zwei Zeilen zuweilen nicht ordentlich weiterläuft.
  http.Disconnect(True);
  http.IOHandler.InputBuffer.Clear;
until (iError > 5);

Im Fehlerfalle behalten ResponseNo und ResponseText (zuweilen, meist, immer?) den Inhalt vom letzten erfolgreichen Aufruf vor dem Fehler, haben hier also genau keine Aussagekraft. Im Zweifel vorher Werte zuweisen, an denen du erkennen kannst: Sind sie unverändert, dann ist das was schiefgelaufen.

[mjustin]

Zitat von Delphi.Narium:

Innerhalb von Indy kannst Du das Problem nicht beheben, da müssten wir mal den Quelltext sehen, der für den Aufruf, die Verbindung, ... zuständig ist,

Der clientseitige Quelltext befindet sich bei Web-Anwendungen ja nicht immer in einer Delphi-Anwendung. Oft ist es einfach ein Web-Browser. Der hat seine eigenen Timeeout-Einstellungen, oder andere Gründe die Verbindung seinerseits einfach zu schliessen.

[Delphi.Narium]

Da es eine Fehlermeldung aus Indy gibt, muss Indy involviert sein.

Aber: Indy ist nicht die Ursache.

Bei einer Verbindung über Indy sind immer zwei beteiligt. Wenn also Indy meldet, dass die Verbindung abgebrochen wurde, so liegt die Ursache bei der "NichtIndySeite", also einem beliebigen Server, einem beliebigen Client.

Flapsig formuliert: Bei EIdSocketError ist man nicht selbst Schuld, sondern muss mit den Folgen des Verbindungsabbruches durch 'ne "externe Stelle" bestmöglich leben. Sprich: Man braucht 'ne passende Fehlerbehandlung im eigenen Quelltext und nicht "irgendwo bei den Indys".

[mjustin]

Zitat von Delphi.Narium:

Da es eine Fehlermeldung aus Indy gibt, muss Indy involviert sein.

Ja, wenn ich es richtig gelesen habe ist Indy der Server:

TIdHTTPResponseInfo.WriteContent; Das ist Indy HTTP Server - Code, ganz eindeutig.

Und der Indy HTTP Server bemerkt, dass ein Client die Verbindung getrennt hat.
Daher wird Indy-seitig eine Exception ausgelöst.