Which Action Makes Java Deserialization Print Wagon : 200?
Given the code fragments: and: Which action prints Wagon : 200? - 
- 
Community Votes
100% of anonymous learners picked answer E. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests that readObject() throws ClassNotFoundException in addition to IOException, and the trap is choosing Serializable (C) when the class already has it and only the unhandled checked exceptions block compilation.
This 1Z0-829 question centers on reading a serialized Car object back with ObjectInputStream, whose readObject() method declares both IOException and ClassNotFoundException. The page establishes that declaring those checked exceptions on the main method (option E) is the only action that lets the fragment compile and print Wagon : 200.
Many learners pick C, assuming the Car class needs java.io.Serializable; the first fragment already declares it, and adding it still leaves the ClassNotFoundException from readObject() unhandled, so the code cannot compile or print anything.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
ObjectInputStream.readObject declares two checked exceptions: IOException for stream and file problems, and ClassNotFoundException, thrown when the deserialized class cannot be resolved on the classpath. In the second fragment the readObject call at line n3 is not covered by handling for ClassNotFoundException, so javac rejects the code before it can ever run. Adding throws IOException, ClassNotFoundException to the main method signature at line n2 satisfies the compiler without changing any logic. Since the Car class in the first fragment is already serializable, the object is written and read back successfully and the program prints Wagon: 200.
Why the Other Options Are Wrong
Option A (AutoCloseable at line n1) is irrelevant: AutoCloseable only supports try-with-resources and plays no role in deserializing a Car instance. Option B (replacing Car with LuxuryCar at line n3) fails because the object written to the file and the expected type are Car, so introducing LuxuryCar fixes neither the cast nor the exceptions. Option C (implementing Serializable at line n1) is redundant because the fragment already declares it, and serializability never removes the checked ClassNotFoundException. Option D (readLine at line n3) is impossible: ObjectInputStream has no readLine method — that belongs to BufferedReader and the deprecated DataInputStream.
Community Comment Notes
The vote is unanimous for E, and commenters such as Tojose and Samps simply restate "the right option is E" together with the full main-signature fix. As SrinivasJasti explains, IOException covers "file-related issues during serialization/deserialization" while ClassNotFoundException is "thrown by ObjectInputStream.readObject" when the class cannot be resolved during deserialization. No comment defends any other option, so the community consensus aligns with the official exception contracts of the Java I/O API.
Official Reference
Exam Strategy
Whenever a fragment calls ObjectInputStream.readObject(), immediately check what the enclosing method handles or declares. ClassNotFoundException is a sibling of IOException, not a subclass, so catch (IOException e) alone never compiles around readObject(). Favor the option that throws or catches both exceptions explicitly.