Determining end of file when file consists of objects

Question

Hi
I'm having trouble working out how to determine end of file when the file consists of multiple objects
I've written multiple Person objects to an XML file and I can read the first back
public Vector<Person> readVectorFromFile() throws CJException {
         Vector<Person> v = new Vector<Person>();
         try {
         XMLDecoder d = new XMLDecoder(new BufferedInputStream(new FileInputStream("VectorStore.xml")));
         // while there are Persons remaining in the file
         Person p;
         //for each p in the file
         do {
             p = (Person) d.readObject();
             v.add(p);                      
         } while(// can't work out how to test this);
         d.close();
         catch(IOException ioe) {
             throw new CJException("Error reading file: " + ioe.getCause());
         }al the books either give examples with the reading of a single object or reading multiple charaters...i've tried testing when p is null and using int c but these give ArrayIndexOutOfBoundsExceptions at runtime.
Please could someone point me in the right direction?
Thanks

Answer 1

paulcw wrote:
Similarly, this sucks:
try {
int i = 0;
while(true)
System.out.println(someArray[i++]);
} catch (ArrayIndexOutOfBounds e) {
// ignore
True, but that is not the case in this instance, if that is what you're getting at. The problem is that the "read" method of this "Reader" throws an ArrayIndexOutOfBounds exception, without providing any way of figuring out if there is even anything to read. And that, in and of itself, is a remarkable event.
The only other ways I see to avoid are all cludge work-arounds or innefficient. You could have the first object in the file be an Integer to indicate the number of objects (but what if, then, for whatever reason, the Stream is "emtpy"). You could parse the XML stream counting the number of "object" elements then push it all back, or reset if the underlying stream supports one of those, or reopen the stream and parse it again (this time with the readObject method), all of which are highly ineffecient. You could transmit, beforehand, how many elements there are, or "define" that there will "always" be only so many elements, etc.
Everyone of those possible solutions (with the exception of the second, which is simply inneffecient) makes the entire thing rigid and inflexible, and, essentially, non-reusable.
The while (or whatever) loop and catch at least make it generally usuable in all situations. It is, I agree, less than optimal, but still the "best" option, in this particular instance.