outputStream kaster ingen Exception

Du finder ud af det gennem læsning, ikke gennem skrivning:

while(true) {
  StringBuffer sb = new StringBuffer();
  int c = -1;
  while (c != 0 && c != 10 && noStopRequested) {
    c = in.read();
    if (c == -1)
      throw new IOException("Server down.");
    if (c != 0 && c != 10)
      sb.append((char)c);
  }
  String receivedData = sb.toString();
} catch(Exception e) {
  e.printStackTrace();
  // serveren er sandsynligvis gået ned
}

Jeg ville forvente en IOException. Fordi den får jo ikke nogen TCP
layer bekræftigelse på pakken.

in.read() vil som arne_v siger kaste en IOException, hvis det opdages, at forbindelsen er afbrudt.

Hmm, jeg tror det må kunne gøres på en eller anden anden måde.

Problemet må være at write() retunerer med det samme, og selve afsendelsen sker senere i en anden tråd. Mon ikke man kan gribe et event når write er helt overstået og teste det der, altså noget asymkromt hvis der er noget som hedder det på 'java' .

Mvh

Du kan på ingen måde være sikker på at forbindelsen er ok, selvom du kan sende. Dermed kan du heller ikke være sikker på at du vil modtage en exception, hvis forbindelsen er afbrudt. Det er altid læsninger fra en stream, der vil medføre fejl, hvis forbindelsen er afbrudt. Enten i form af en smidt IOException, eller hvis du modtager bytes med værdien -1.

Det an jeg ikke tro på er rigtigt..... Jeg tror godt at man på en eller anden måde kan sende, og så få en besked når afsendelsen er overstået og om det gik godt eller dårligt. Det må man kunne, ellers er der sku da noget galt med Java,

Du kan kun være sikker på at du får en bekræftelse på afsendelsen, hvis den server du sender beskeden til svarer tilbage. Det jeg siger er ikke, at du aldrig vil opdage at forbindelsen er afbrudt når du sender, men oftest kan du ikke være sikker på det. Grunden er ikke Java, men den underliggende TCP-service, der endnu ikke har opdaget at forbindelsen er afbrudt.

Man får kan få et callback i c#, så det skyldes ikke TCP. Jeg vender tilbage.

Jeg mener at send vil time ud og give en exception når TCP/IP stakken
opgiver at retransmitere fordi den ingen bekræftigelse får.

Det virker rigtigt som du skriver dsj, nu kaster read en exception når jeg sender til er server der er væk.

Synes bare det er noget rod, det kan jo være lidt svært at styre hvilken data klienten så ikke har fået sendt til serveren. Det ville være meget lettere hvis der blev kastet en exception af write, ligesom c# gør.