• Post Reply Bookmark Topic Watch Topic
  • New Topic

how to know when ObjectInputStream do not have anything to read ?

 
Sam Cala
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,
How to know when InputStream(say ObjectInputStream) reaches End of Stream ?
What I'm doing is calling readObject() in an infinite loop. So, if there is nothing to be read from outputstream, it throws EOFException. So, I want to know if there is anything to be read in stream or not before invoking readObject() method. If yes, only than I will invoke readObject() method ...
Regards,
 
SAFROLE M3
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why dont you just test for 'null' after a call to readObject()?
SAF
 
Rajakumar Makapur
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
try with available() method before calling readobject().
regards
Rajakumar Makapur.
 
Jan Sauerwein
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thats an well known problem.
The tip with available ( ) sucks, cause it is to often wrong.
Also the test if the Object is null wouldn't work. Cause the EOFException is thrown before.
There is only a very dirty possibility:
Catch the exception is thrown when there are no datas left. And handle it. It is the only way to solve your problem.
If there is someone want to contradict me, let it be. I'll give you an example where any other way does not work.
Hope it helps
j.a.n.s
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan appears to be correct. For the general question about how to determine the end of an InputStream, most input streams have a way of indicating a stream end cleanly - either by returning a -1 or a null, depending on context. But the ObjectInputStream does not include such a method in its API. I don't know why. But catching an EOFException is not a bad way to handle the situation. Object deserialization is fairly slow to begin with - the extra overhead of creating, throwing, and catching an exception is not going to be particularly noticeable in this case, I think.
 
Sam Cala
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi !
Thats what I also think cause I wasn't able to find any solution for this ! Thanks Jan and Jim !
Jan, it would have been more better if you could give me some example for the purpose to get the topic more clearer.
Thanx and Regards,
 
Omar IRAQI
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends,
I totally agree with Jan Sauerwein, about what he said.
However, there is a way to avoid throwing the exception if there is an agreed-on communication protocol between the server and the client. So the server would notify the client, according to the protocol, that EOF has been reached, and the client would then leave the reading state without noise.
This solution is clean and feasible but only if you are writing both the client and the server, so that you can implement your own protocol. Now if you are writing a client for an already existing Server, say Http server, try to know how that server notifies that there is no more data to send.
If the server does not notify such event, follow Jan Sauerwein's advise.
cheers.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!