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.

• ✗

  Catch Exception in a single handler and inspect the message text to decide which error occurred.

  Why it's wrong here

  Catching the broad Exception class hides unrelated bugs and forces fragile string matching on the message, which varies across platforms and Python versions. It also does not reliably distinguish a missing file from a permission problem, because both are OSError subclasses with different messages. This approach undermines the requirement to handle each condition distinctly and makes the function harder to maintain.

• ✗

  Open the file without a with statement and call close() only after the parsing code completes successfully.

  Why it's wrong here

  Calling close() only on the success path leaves the file open when parsing raises an exception, which violates the requirement to close on every path. To be correct without with, the close would need to be in a finally block. Relying on the success path alone is exactly the resource-leak pattern the scenario is trying to avoid.

• ✓

  Catch FileNotFoundError and PermissionError in separate except clauses to produce distinct error messages.

  Why this is correct

  FileNotFoundError and PermissionError are distinct subclasses of OSError, so separate except clauses allow the function to report a missing file differently from a permission problem. This satisfies the requirement to distinguish those two cases. A malformed file would still need separate handling, such as catching a parsing exception, but these two clauses cover the file-access distinctions the scenario calls out.

• ✓

  Use a with open(...) as f: block so the file is closed whether the body succeeds or raises.

  Why this is correct

  The with statement creates a context manager whose __exit__ closes the file even if an exception occurs inside the block. This directly satisfies the requirement that the file must not be left open on any path. It also keeps the code concise and avoids the common bug of forgetting to call close() in a finally clause when multiple branches are involved.

• ✗

  Rely on the garbage collector to close the file when the function returns, and raise a custom exception for all failures.

  Why it's wrong here

  CPython often closes a file when its reference count drops to zero, but this is an implementation detail and not a language guarantee; other implementations may delay it. Relying on the garbage collector can leave the file open longer than intended and is not a deterministic cleanup strategy. Raising one custom exception for all failures also fails the requirement to distinguish missing, permission, and malformed cases.

Go deeper

Related to this question