PCAP Exceptions and File I/O Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use os.path.exists before opening the file, and if it returns False, log and skip.

  Why it's wrong here

  This look-before-you-leap (LBYL) approach is vulnerable to a time-of-check to time-of-use race condition: the file can be deleted, renamed, or lose permissions between the os.path.exists() call and the subsequent open(), which will then raise an exception that is never handled. Additionally, os.path.exists() only verifies path existence, not that the file is readable, holds a valid CSV, or that the underlying network share is responsive, so a false positive still leads to an unhandled failure. Even if the check returns False properly, logging and skipping the file silently means data can be dropped without any retry or alerting, which is unacceptable for a production data processing pipeline.

• ✓

  Use a try-except block catching OSError, with a retry loop that logs the error and continues after max retries.

  Why this is correct

  This is the correct strategy because it follows the easier-to-ask-forgiveness-than-permission (EAFP) idiom and catches OSError exactly, which is the base class for I/O failures such as FileNotFoundError, PermissionError, and BrokenPipeError. The retry loop with a maximum retry count is essential for transient network-drive hiccups or brief file locks, while logging the specific error and the retry attempt gives operators visibility into what happened. After exhausting the retries, the loop logs the final failure and continues to the next file, ensuring the pipeline does not crash on a single bad input. This approach is precise, non-recursive, and aligns with best practices for robust file processing.

• ✗

  Use a try-except block catching Exception, with a retry loop and logging.

  Why it's wrong here

  Catching the overly broad Exception class is dangerous because it will trap not only the intended file I/O errors but also programming mistakes like TypeError from malformed arguments, AttributeError from mis-typed variables, or ValueError from bad CSV data — none of which will be fixed by retrying. These bugs should fail fast so developers can detect and correct them, but wrapping them in a retry loop only masks them and makes the pipeline continue with corrupted or incomplete data. A retry loop is only justified for exceptions that are known to be transient, and Exception includes too many permanent, non-retryable conditions; the correct choice is to catch OSError specifically, which covers the realistic file-related failures.

• ✗

  Use a with statement; if an exception occurs, call the function recursively up to 3 times.

  Why it's wrong here

  Recursive retry (calling the processing function upon exception) is a poor design because it forces the retry count to be controlled by recursion depth, and while a fixed depth of 3 is unlikely to hit Python's recursion limit, the approach is still needlessly complex and wastes stack frames on every retry. More importantly, recursion makes control flow harder to trace and test, and the retry counter must be threaded through the function signature or a closure, which is error-prone. A simple iterative loop (e.g., for attempt in range(max_retries)) is clearer, more memory efficient, and avoids any risk of recursion-related bugs; the with statement that follows has no bearing on whether retries are implemented as a loop or recursion.

Go deeper

Related to this question