aspose file tools*
The moose likes I/O and Streams and the fly likes Unable to read the second object in the file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "Unable to read the second object in the file" Watch "Unable to read the second object in the file" New topic
Author

Unable to read the second object in the file

Chiranjib Bhattacharjee
Greenhorn

Joined: Nov 08, 2012
Posts: 12

Below is the code for writing and reading objects. While reading, I am able to fetch the first object, in the do-while loop, but when it runs for the second time, it throws java.io.StreamCorruptedException
I am clueless. Please help.



~ godspeed.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2316
    
  49
Welcome to the Ranch.

Firstly you are only writing one object to the stream so the second attempt to read an object will throw an exception albeit not the one you are getting.
Secondly why are you calling reset() after writing the first object. The API docs say "Reset will disregard the state of any objects already written to the stream. The state is reset to be the same as a new ObjectOutputStream....".
Chiranjib Bhattacharjee
Greenhorn

Joined: Nov 08, 2012
Posts: 12

I call the write method multiple times. So, there are more objects in the file I know.
And well, I could remove the reset() statement, tried that too, didn't work.
Any other pointers?
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2316
    
  49
I call the write method multiple times. So, there are more objects in the file I know.

Well that could be your problem. I don't think you can just append to a file created by an ObjectOutputStream. Try writing all the objects in one go and see if it works.
Chiranjib Bhattacharjee
Greenhorn

Joined: Nov 08, 2012
Posts: 12

Oh alright. But I don't think I can write all the objects at one go. Still, will try to tweak a little then. Thanks.
Chiranjib Bhattacharjee
Greenhorn

Joined: Nov 08, 2012
Posts: 12

Solved it. Thought I'd share.
Solution: I initialized ObjectOutputStream in the class constructor instead of the method, so that the object has the same stream for writing all the objects. Closed the stream at a later point of time, when releasing the resources. I had multiple threads calling the write method and I could successfully append to the file. While reading though, traversal of the file was successful, but after the last object it threw an java.io.EOFException. I caught it and returned an array of retrieved objects anyway. Not healthy maybe, but served the purpose!
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2316
    
  49
I had multiple threads calling the write method and I could successfully append to the file.

Yes, you can keep appending whilst the same stream is open, what you can't do is close the stream and re-open it with the FileReader set to append mode and then add more objects.

While reading though, traversal of the file was successful, but after the last object it threw an java.io.EOFException. I caught it and returned an array of retrieved objects anyway. Not healthy maybe, but served the purpose!

That is the way it is supposed to work. There is no way of finding if there are any more objects other than trying to read one in and handling the EOFException. Personally I think this is the wrong way for the class to handle an EOF but that's the way it is designed to work and there isn't a whole lot we can easily do about it.
Chiranjib Bhattacharjee
Greenhorn

Joined: Nov 08, 2012
Posts: 12


That is the way it is supposed to work. There is no way of finding if there are any more objects other than trying to read one in and handling the EOFException. Personally I think this is the wrong way for the class to handle an EOF but that's the way it is designed to work and there isn't a whole lot we can easily do about it.


Oh alright. Peace of mind!
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tony Docherty wrote:
While reading though, traversal of the file was successful, but after the last object it threw an java.io.EOFException. I caught it and returned an array of retrieved objects anyway. Not healthy maybe, but served the purpose!

That is the way it is supposed to work. There is no way of finding if there are any more objects other than trying to read one in and handling the EOFException. Personally I think this is the wrong way for the class to handle an EOF but that's the way it is designed to work and there isn't a whole lot we can easily do about it.


I can kind of see the logic behind it. The contents can vary drastically, and there are hooks to provide custom writing and reading, so it might not have been practical to provide an isThereAnotherObject method that does anything other than the same try/catch we'd do. Plus, if we don't even know if there's another object, then if there is one, how would we even know what type it would be and how to deal with it? And finally, since it's generally trivial to just write an entire object graph with a single call and then read it back with a single call, the need for testing for "more objects left?" is reduced to almost nothing.

In short, I think it comes down to the combination of foreknowledge that we have to have to make use of the serialized objects plus the flexibility of how we write them making it trivial for us to write such that we don't need ask the stream if there's anything left.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2316
    
  49
Jeff Verdegan wrote:I can kind of see the logic behind it...

Yes I understand your points, I just don't think it's right to use Exception handling as a way of saying there are no more objects. IMHO reaching the end of the stream isn't an exceptional condition.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tony Docherty wrote:
Jeff Verdegan wrote:I can kind of see the logic behind it...

Yes I understand your points, I just don't think it's right to use Exception handling as a way of saying there are no more objects.


I agree completely. My point is, there's no need to do it, if the objects were written out correctly.


IMHO reaching the end of the stream isn't an exceptional condition


IMHO, not knowing you've reached the end of some serialized objects and should stop reading is an exceptional condition.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2316
    
  49
Jeff Verdegan wrote:I agree completely. My point is, there's no need to do it, if the objects were written out correctly.

Ok, I see what you mean.

Jeff Verdegan wrote:IMHO, not knowing you've reached the end of some serialized objects and should stop reading is an exceptional condition.

Fair point.

Although if we take this to the extreme why doesn't it restrict you writing a single object (with its complete object graph) and then you could only read a single object back in and further attempts to read would genuinely be an exception
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Unable to read the second object in the file