PCAP Exceptions and File I/O Practice Question
A developer runs a script that reads records from a binary file. After a partial read, the storage device is unplugged, and the read() call raises OSError. The developer wants the script to retry the read a few times before giving up, but only for this transient I/O problem. Which exception should be caught to retry specifically on this failure?
⚠ Common exam trap
The trap here is assuming that IOError is a separate, more specific exception from OSError, when in Python 3 IOError is just an alias for OSError.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
OSError
A transient device failure during read() surfaces as OSError, the common base for I/O errors. Catching it around the read permits a bounded retry while still allowing non-I/O exceptions to propagate. The other listed exceptions describe unrelated conditions and would not catch this failure, so they cannot drive the retry behavior the scenario requires.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
RuntimeError
Why it's wrong here
RuntimeError is raised for generic runtime problems that do not fit other categories, not for device I/O failures. A read() on a file whose device was unplugged raises OSError, so a RuntimeError handler would never run and the retry logic would silently not execute. Retrying on RuntimeError would also mask unrelated programming mistakes instead of the transient read error.
- ✗
EOFError
Why it's wrong here
EOFError is raised by input() when it hits end-of-file without reading data, and by some interactive protocols. It does not describe a failed read() on a binary file after a device is unplugged; that failure is an OSError. Catching EOFError here would not catch the transient I/O condition, and it could accidentally swallow an unrelated input-related problem.
- ✓
OSError
Why this is correct
OSError is the base class for I/O failures such as a device being unplugged, and read() raises it when the underlying read fails. Catching OSError around the read allows a bounded retry loop for this transient hardware problem, while still letting unrelated errors propagate. Because FileNotFoundError and PermissionError inherit from OSError, the handler should inspect errno or use a narrower subclass if those must be handled differently.
- ✗
IOError
Why it's wrong here
IOError is an alias of OSError in Python 3, so writing it here is not wrong at runtime, but it is an outdated name that adds confusion. In this scenario the read failure is already reported as OSError, and using the current name keeps the code clear. More importantly, catching IOError is not a narrower or more specific way to handle a transient device failure; it is the same class.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCAP question from scratch — 421 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Python Institute exam blueprint
This PCAP practice question is part of Courseiva's free Python Institute certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCAP exam.