System.IO.IOException-Ausnahme beim Versuch zu Ende-thread
Ich Lerne netcode und multithreading in Monodevelop unter Verwendung von C# mit GTK#. Hab ich nie gemacht vorher, und jetzt finde ich mich brauchen, um beides auf einmal.
Ich habe eine tutorial-chat-Programm, das keine Handhabung von Fehlern, und das habe ich gefangen, dass ein Fehler passiert, in der client jedes mal, wenn ich vom server getrennt. Der code sitzt in einem thread auf eingehende Nachrichten warten, ist wie folgt, umgeben von try/catch-Anweisungen:
try
{
while (Connected)
{
if (!srReceiver.EndOfStream && Connected)
{
string temp = srReceiver.ReadLine();
//Show the messages in the log TextBox
Gtk.Application.Invoke(delegate
{
UpdateLog(temp);
});
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
Nach dem die Funktion beendet und der thread beendet.
Den code, endet die Verbindung sieht so aus und läuft auf dem main thread:
private void CloseConnection(string Reason)
{
//Show the reason why the connection is ending
UpdateLog(Reason);
//Enable and disable the appropriate controls on the form
txtIp.Sensitive = true;
txtUser.Sensitive = true;
txtMessage.Sensitive = false;
btnSend.Sensitive = false;
btnConnect.Label = "Connect";
//Close the objects
Connected = false;
swSender.Close();
srReceiver.Close();
tcpServer.Close();
}
Und der try/catch-Anweisungen über Fang dieser Fehler:
System.IO.IOException: Unable to read data from the transport
Verbindung: Ein blockierungsvorgang wurde unterbrochen durch einen Aufruf von
WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: Ein
blockierende operation wurde unterbrochen durch einen Aufruf von WSACancelBlockingCallSystem.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32
offset, Int32 size)--- Ende der inneren Ausnahme-stack-trace - - -
System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32
offset, Int32 size)System.IO.StreamReader.ReadBuffer()
System.IO.StreamReader.get_EndOfStream()
in ChatClientGTK.MainWindow.ReceiveMessages() in
g:\Android\Tutes\ChatClientRemake\ChatClientGTK\MainWindow.cs:Zeile 157
Nun, soweit ich das beurteilen kann, wenn srReciever.Close() geschieht in der main-thread, srReciever.ReadLine() ist immer noch versuchen zu führen, in dem listening-thread, wo das problem liegt, aber selbst wenn ich kommentieren srReciever.Schließen(), ich bekomme immer noch den Fehler.
Soweit ich das beurteilen kann, gibt es keine Nebenwirkungen verursacht, die nur durch den Fang den Fehler und bewegen auf, aber nicht wirklich sitzen bei mir richtig. Brauche ich, um diesen Fehler zu beheben, und wenn ja, hat jemand irgendwelche Ideen?
- Nur ein weiteres Beispiel für eine Ausnahme ausgelöst wird, um anzuzeigen, dass ein nicht-außergewöhnlichen Zustand. Die meisten Menschen denken, schlechte API-design, aber mit .NET BCL es ist an der Tagesordnung.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Statt mit einem ReadLine, kannst du nicht einfach eine Lese-und Aufbau der Saite, bis ein CrLf erkannt wird dann ausgegeben, dass die update-log.
ReadLine ist ein blockierender Aufruf heißt, es wird dort sitzen und immer Fehler, wenn die Verbindung geschlossen wird.
Sonst könnte man ja einfach den Fehler ignorieren. Ich weiß, was Sie meinen, wenn Sie sagen, es sitzt nicht richtig, aber es sei denn, jemand kann mich aufklären, ich sehe nicht, dass es irgendein Leck in der Ressourcen wegen, und wenn es ist ein erwarteter Fehler, dann kann man entsprechend behandeln.
Ich würde auch wahrscheinlich fangen die Besondere Ausnahme
Den Fehler in Ordnung ist. Wenn Sie es wirklich wollen, Weg zu gehen, können Sie ein "bye" - Befehl in Ihrem Protokoll. Also, wenn der server entscheidet, sich zu trennen, direkt bevor die Verbindung getrennt wird, sendet er ein "bye" an den client, sodass der client trennt die Verbindung zu, und die meisten sind die Chancen, dass die exception nicht geworfen werden. Aber man sollte doch bereit sein, es zu fangen, wenn es jemals bekommt geworfen. Und dann ignorieren Sie es.