Was spricht denn generell dagegen auf diese EOFException zu reagieren und den Socket und die Stream zu zu machen?
die tatsache das man sich , wenn man es SAUBER macht , nicht um irgendwelche Exceptions kümmern muss ... weil man eben die möglichkeit hat einen SAUBEREN verbindungs
abbau von der jeweiligen seite die die verbindung beenden möchte VORHER sauber dem gegenüber zu signalisieren was darauf dann entsprechend SAUBER reagieren kann ...
Also ist das in dem fall kein Exception-Missbrauch?
in meinen augen ist es das schon ...
ich versuch dir mal meine sich von "exception-missbrauch" an hand dieses beispiels hier zu erklären
FALL 1 : abbruch mit exception
der client will die verbindung trennen ... und macht dazu das einfachste der welt : die verbindung "gewaltsam abwürgen" ...
die probleme die hierbei entstehen können ist das es die tiefer liegenden netzwerkschichten so nicht ganz begreifen um entsprechend dem protokoll der gegenseite eben dieses "gewaltsame abwürgen" der verbindung zu signalisieren ...
falls das funktioniert kann man auf der gegenseite noch mit ner fehlermeldung "rausspringen" ... muss dann aber seinen code so anpassen das irgendwie in jedem fall noch versucht wird irgendwas aufzuräumen ... falls man hier nicht genau so mit offenen resourcen umgeht ... was zu einer kettenreaktion führen kann die das gesamte programm abstürzen lassen kann ..
versagen eingebaute sicherheitsmechanismen jedoch bleibt viel an ungenutzen resourcen offen und gesperrt ... bedeutet höhere system-auslastung und deadlocks ...
EXCEPTIONs bedueten das ein FEHLER aufgetreten ist ... "checked" exceptions sind dabei fehler auf die man reagieren MUSS ... "unchecked" exceptions ... also RuntimeException und alles was davon erbt sind die sog. "unerwarteten Fehler" ... die meist schwere systemschäden zur folge haben ...
folgend dieser beschreibung darf man exceptions wirklich nur für fehlerfälle nutzen ... also wenn halt eine verbindung "abreist" ... und nicht von einem der beiden seiten "gewaltsam abgewürgt" wird ...
FALL 2 : sauberer abbau mit signalisierung
der client will wie oben wieder die verbindung trennen ... schickt dem server aber vorher erstmal eine nachricht : "hey, du, ich will die verbindung trennen" ...
der server reagiert auf diese nachricht und prüft erstmal ob dieser vorgang jetzt gerade im momment überhaupt zulässig ist ... oder ob der client noch in einer transaktion hängt für die er benötigt wird und die verbindung daher nach möglichkeit nicht trennen sollte ...
das ergebnis dieser auswertung kann dann wieder zum client geschickt werden der dies auswerten kann um darauf zu reagieren ... und falls halt noch daten zu senden sind diese liefern oder daten vom server noch verarbeiten und speichern ...
nach dem nun beide seiten sich auf die freigabe der verbindung geeinigt haben beginnen sie gegenseitig ihre resourcen freizugeben und die kommunikations-kanäle zu schließen ... und zum schluss die socket-verbindung sauber zu trennen ...
im einfachsten fall sieht das dann so aus das der client zum server sagt : "trennen" ... der server antwortet : "ok" ... und beide dann einfach auf die streams und den socket "close()" callen ...
der vorteil liegt auf der hand : beide seiten können der anderen noch sagen das der verbindungsabbau zur zeit eventuell noch ungüstig ist oder halt noch die letzten daten senden ...
außerdem können resourcen sauber aufgeräumt und wieder an das system freigegeben werden ... vorrausgesetzt man geht mit seinen resourcen gewissenhaft um ...
und genau DIESEN unterschied bezeichne ich als "exception-missbrauch" ... da ein "fehlerfall" dafür "missbraucht" wird einen "gewollten zustand" zu signalisieren ...
bestes beispiel stellen eigentlich alle read-operationen dar : es kommt einfach "-1" zurück wenn der stream zu ende ist ... eine EOF(EndOfFile)Exception sollte (und wird) nur dann geworfen wenn der datenstrom früher als angenommen zuende ist ... wobei sich die entwickler keine mühe gemacht haben EndOfFile und EndOfStream zu unterscheiden ...
ich hoffe ich konnte dir das problem etwas näher bringen ...
was mich allerdings immer noch wundert ist das bei dir "ObjectInputStream.readObject()" NICHT auf "Socket.setSoTimeout()" reagiert ... denn genau das sollte es eigentlich und wie bernd und ich schon sagten eingentlich eine IOException werfen ... das ist auf jeden fall was für den bug-tracker