[Socket] Tester une fermeture soudaine d'un client

Bonjour,

J'inaugure mon compte par ce petit problème surement anodin, mais comme je suis assez jeune dans le réseau en Java, je ne vois pas trop la méthode la plus adaptée à utiliser. Donc j'en appelle à vos grands savoirs (:

Voila, j'ai donc mis en place un client et un serveur, qui communiquent à merveille. Lors de l'utilisation du serveur, celui-çi attend à un moment un objet à désérialiser.
Lorsque le client est toujours connecté, la seria / deserialisation se fait sans problème.
Seulement, quand je coupe soudainement et brutalement le client, cela entraine une levée d'exception (EOFException) au niveau du serveur.

Voila le problème s'il en est un, j'ai trouvé là methode "isConnected" qui me permettrait apparement de tester avant l'attente de deserialisation si le socket est toujours connecté ou non, seulement le serveur me répond tjrs que oui. Donc peut-etre que je fais fausse route sur cette méthode.

Donc voila, auriez-vous une méthode qui me permettrait de détecter si le socket est toujours viable, ou alors je dois passer par un catch lors d'un envoi de test sur le socket (ce qui me parait un peu brutal).

Je vous remercie de l'aide éventuel, ca m'intrigue un peu tout ça (:

Bonne soirée !

La méthode la plus efficace est de catcher l'IOException lors du read :

Code:

---

1 2 3 4 5 6 7 8

try{ while(...){ monSock.read(...); } }catch(IOException ioe){ System.out.println("Connexion rompue."); }

---

Oki je te remercie, finalement j'étais parti sur le même type de test, ça me paraissait un peu bourrin malgré tout, mais si c'est le plus efficace !

'journée ;)

Effectivement, c'est la méthode normale pour gérer la déconnexion.
Attention dans l'idée à ne pas confondre Exception et erreur ... Gérer une Exception dans le catch peut être un cas totalement "standard" !

N'oublie pas le tag :resolu:

Avec l'habitude, une exception n'est plus du tout synonyme d'erreur. Les exceptins permettent dans de nombreux cas de gérer une situation de façon élégante