Courseiva
Exceptions and File I/OmediumMultiple ChoiceObjective-mapped

PCAP Exceptions and File I/O Practice Question

A developer is building a logging system that writes logs to a file. The system should handle disk-full situations gracefully without crashing the main application. Which approach is appropriate?

⚠ Common exam trap

Python Institute often tests the distinction between catching overly broad exceptions (Option B) versus catching specific exceptions (Option D), and the trap here is that candidates may think 'catching all exceptions' is a safe catch-all, but it actually hides programming errors and violates Python best practices.

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

Wrap the log write in a try/except that catches OSError and writes to stderr as fallback.

It uses a targeted try/except block around only the log write operation, catching OSError (which includes disk-full conditions) and falling back to stderr. This prevents the main application from crashing while still reporting the error, adhering to the principle of handling exceptions at the point where they occur and only when you can meaningfully recover.

Answer analysis

Option-by-option breakdown

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

  • Check disk space before each write; if low, skip logging.

    Why it's wrong here

    Pre-checking available free space with os.statvfs or shutil.disk_usage introduces a time-of-check-to-time-of-use race: another process can consume the remaining space between the check and the actual write, so the write may still raise OSError. It also doubles the I/O cost of every log call and, by skipping logging, silently drops records that should have been stored. A try/except around the write is both cheaper and more reliable.

  • Wrap the entire application in a try/except that catches all exceptions.

    Why it's wrong here

    Wrapping the entire application in a broad try/except (such as except Exception) treats unrelated programming errors — ValueError, TypeError, AttributeError — as if they were logging failures, allowing the program to continue in an undefined state and hiding bugs. It also does not provide a targeted fallback for OSError specifically; the stderr fallback would fire for any exception, masking the root cause of crashes. Moreover, this approach does nothing to prevent the original logging call from failing and is no substitute for a dedicated logging boundary.

  • Let the OSError propagate to the main program's exception handler.

    Why it's wrong here

    Allowing the OSError to propagate to a global handler means the logging call itself is aborted and the log record is lost; if the handler is not a perfect catch-all, the application may still crash. Even if the main program's exception handler does not terminate the process, it cannot tell which subsystem failed without clunky logic, and an unhandled disk-full error from a background thread or callback may take down the whole service. A logging system should degrade the logging subsystem, not the application logic.

  • Wrap the log write in a try/except that catches OSError and writes to stderr as fallback.

    Why this is correct

    Wrapping only the write operation in a try/except that specifically catches OSError is the correct pattern: OSError is the parent class of errors like disk full, permission denied, and other I/O failures, so it captures the exact failure mode. Falling back to sys.stderr preserves the log entry and keeps the application running; if stderr itself fails, you can chain another exception or silently drop the record, but the primary failure is isolated. This targeted fallback also avoids hiding non-I/O bugs, unlike a global exception handler.

About these practice questions

This PCAP question is part of Courseiva's 169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

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.