Exceptions and File I/O practice questions

PermissionError

Why wrong: PermissionError is also a subclass of OSError, but it is raised when the operating system denies access to a resource due to insufficient permissions, such as read, write, or execute rights. In the scenario of a missing configuration file, the file is absent rather than being blocked by permissions, so the failure occurs earlier in the lookup process and does not involve access control. Choosing PermissionError would misidentify the root cause and complicate debugging.

IOError

Why wrong: IOError is an alias for OSError in Python 3; it is a broad category that covers many I/O failures, including missing files, permission issues, and device errors. While a missing configuration file would technically trigger an OSError, IOError is too generic and does not convey the specific reason—the file's absence—that a developer needs to handle. Relying on IOError forces the error handler to parse the error code or message to distinguish between failure modes, which is unnecessary when FileNotFoundError exists.

OSError

Why wrong: OSError is the parent class for most operating-system-related errors, including FileNotFoundError, PermissionError, and many others. Catching OSError for a missing configuration file is overly broad and would also catch unrelated errors like disk full or connection reset, masking the actual problem. FileNotFoundError is a more specific subclass, allowing precise handling and clearer error reporting, which is why OSError alone is inappropriate.

Wrap the entire file reading in a try-except block without specifying exception type.

Why wrong: Wrapping the entire file reading in a bare try-except block masks every exception, including genuine programming errors like a NameError or KeyError in your parsing logic, making the script fail silently. Even if a UnicodeDecodeError occurs, the whole read loop aborts on the first bad line, so you cannot skip that line and continue processing the rest of the file. A bare except also catches KeyboardInterrupt and SystemExit, which can make the script impossible to interrupt cleanly.

Use a try-except-else block to handle success and failure separately, exiting on failure.

Why wrong: A try-except-else structure with an explicit exit on failure directly contradicts the stated goal of processing the log file continuously. The else clause only runs if no exception was raised in the try block, so it doesn't help isolate a single decoding failure—the exception would still abort the iteration. Calling sys.exit() or break on the first UnicodeDecodeError discards every subsequent line, which is exactly the opposite of skipping only the malformed record and moving on.

Catch Exception in the outer loop and break on error.

Why wrong: Catching Exception is far too broad because it intercepts not only UnicodeDecodeError but also every other exception type, including programming errors like AttributeError or IndexError that indicate actual bugs in your logic. Adding break on any error means the loop stops permanently at the first problem line, losing all subsequent log entries and defeating the purpose of line-by-line processing. A targeted except UnicodeDecodeError with continue is the only way to both skip malformed lines and keep the script resilient.

open('file.txt', 'x')

Why wrong: The 'x' mode performs exclusive creation: it creates a new file for writing but raises FileExistsError if the file already exists. This mode is intended for atomic file creation to prevent accidental overwrites, not for opening an existing file to write. Since the question asks simply for opening a file for writing, 'x' is unsuitable because it cannot handle the common case of an existing file.

open('file.txt', 'r+')

Why wrong: The 'r+' mode opens the file for both reading and writing without truncating it. The file pointer starts at the beginning, so any write operation overwrites existing bytes from that position, leaving the remainder of the file intact. This mode is useful for in-place updates, but it does not meet the requirement of opening a file for a fresh, overwriting write.

open('file.txt', 'a')

Why wrong: The 'a' mode opens the file for writing, but all data is appended to the end of the file, and existing content is preserved. The initial file position is forced to the end, and even explicit seeks are often ignored on writes, ensuring no data is overwritten. This contradicts the goal of opening a file for a general write that starts at the beginning with truncation.

f.seek(4)

Why wrong: f.seek(4) moves the file pointer to byte offset 4 from the start of the file, but it does not read or return any data. This is a repositioning operation, not a data retrieval one, so the script would get no bytes from the file. For reading a 4-byte chunk, you must use a read method; seek only changes where the next read or write will occur, making it useful for skipping headers or jumping to specific offsets, not for extracting data itself.

f.readline()

Why wrong: f.readline() reads bytes until a newline character (b'\n') is encountered, and in binary mode it returns those bytes including the newline if present. This is inappropriate for reading exactly 4 bytes, because the length of the returned chunk depends on where the next line terminator appears, not on a fixed size. Binary data often contains arbitrary byte values that may not include newlines frequently or may include them at unpredictable positions, so line-based reading cannot reliably retrieve fixed-width data structures.

f.read()

Why wrong: f.read() with no argument reads the entire remaining contents of the file into memory as a single bytes object. If the script only needs 4 bytes, this is grossly inefficient for large files, potentially exhausting memory and defeating the purpose of streaming or chunked processing. It also violates the intent of the fixed-size read implied by the code structure, and the file pointer advances to the end, making subsequent reads return b'' unless you explicitly seek backward.

No output

Why wrong: Even if the input is '0', int('0') succeeds, so no conversion error occurs; the subsequent division 10 / 0 raises ZeroDivisionError, which is caught and prints 'Division by zero'. Since the except clauses are the only print statements, and one of them always executes for any input, the program cannot produce no output. A silent exit would require all exceptions to be unhandled, causing a traceback instead.

Both 'Invalid integer' and 'Division by zero'

Why wrong: After int() successfully converts the input '0' to the integer 0, the division operation raises ZeroDivisionError, and control transfers immediately to that handler. Python's exception handling is exclusive: only the first matching except block executes, and once it runs, the remaining except clauses are skipped. Thus 'Invalid integer' is impossible because a ValueError was never raised, and the two messages cannot be printed in the same run.

Invalid integer

Why wrong: A ValueError occurs only when int() encounters a string that does not represent a valid integer, such as 'abc' or '12.5'. The string '0' is a valid decimal integer literal, so int('0') succeeds and returns 0, meaning the ValueError handler is never entered. Consequently, the program never prints 'Invalid integer'; instead, it continues to the division and fails later with a different exception type.

except FileNotFoundError, PermissionError:

Why wrong: Invalid syntax: this comma-separated form was inherited from Python 2, where `except E, e` assigned the exception instance to `e`. Python 3 removed that syntax; you must use `except E as e` or supply a tuple. Without parentheses, Python parses the comma as a tuple construction and raises a SyntaxError, so the line will not even compile.

except OSError:

Why wrong: Catching `OSError` is overly broad: it will intercept every subclass of OSError, including FileNotFoundError and PermissionError, but also IsADirectoryError, NotADirectoryError, TimeoutError, and other low-level I/O errors. This can hide programming bugs and make error handling ambiguous. To handle only the two intended errors, catch the exact classes, not the parent class.

except [FileNotFoundError, PermissionError]:

Why wrong: Using a list literal for the exception targets is not permitted. The `except` clause requires an exception class or a tuple of classes; a list is not hashable and does not inherit from BaseException. The interpreter will raise `TypeError` when an error occurs because it cannot match against a list object, so this code will not work at runtime.

raise

Why wrong: A bare `raise` statement is only valid inside an `except` block, where it re-raises the currently handled exception and preserves its original traceback. Using it outside an `except` block raises `RuntimeError: No active exception to re-raise` because there is no active exception to propagate. It does not create a new exception; it merely forwards an existing one, so it is not a general-purpose way to raise an error.

throw ValueError('error')

Why wrong: The keyword `throw` does not exist in Python; the language uses `raise` to trigger exceptions. If you write `throw ValueError('error')`, Python interprets `throw` as an ordinary identifier, so unless a function named `throw` happens to be defined in the current scope, this raises a `NameError` at runtime. Even if a `throw` function existed, it would not be recognized as the built-in exception-raising mechanism, making this syntactically valid but semantically wrong.

It can only be used with files.

Why wrong: The `with` statement is a general-purpose context management protocol, not a file-specific feature. Any object that implements the `__enter__` and `__exit__` methods—such as `threading.Lock`, `socket.socket`, or a custom class—can be used in a `with` statement. File objects are merely one common example, so limiting `with` to files would ignore many other valid resource types.

It can only handle one file at a time.

Why wrong: A single `with` statement can manage multiple resources by comma-separating context managers, e.g., `with open('a') as f1, open('b') as f2:` opens two files simultaneously. Alternatively, nested `with` blocks can handle any number of files and other resources. Thus, there is no restriction to one file at a time; the syntax explicitly supports multi-resource acquisition.

CustomException

Why wrong: CustomException is not a built-in Python exception; it represents a placeholder for user-defined exception classes. Developers typically create such classes by subclassing the built-in `Exception` base class (or a subclass like `RuntimeError`) to handle application-specific error conditions. The Python standard library does not include any class named `CustomException`, so seeing it in code signals a custom, project-specific definition.

InputError

Why wrong: InputError is not a built-in exception in Python's standard library. The built-in `ValueError` is the closest match, raised when a function receives an argument of the correct type but an inappropriate value, while `TypeError` handles type mismatches. Although some third-party libraries or frameworks define an `InputError` class, the Python language itself does not provide one, so referring to it as a built-in exception is incorrect.

FileReadError

Why wrong: FileReadError is not a built-in exception in Python; the standard library includes `OSError`, `IOError` (an alias of `OSError`), and more specific subclasses like `FileNotFoundError` and `PermissionError`, but no `FileReadError`. This name might appear in custom code, third-party libraries, or other programming languages, but it is not defined in Python's `builtins` or `exceptions` modules. Using it without a custom definition raises a `NameError`, so it cannot be considered a built-in exception.

Prints all lines in the file.

Why wrong: The loop never prints the lines it reads; it only checks for the substring "ERROR" and raises an exception at the first match. That raise immediately exits the loop, so no line-by-line output is produced, and the except block prints a single diagnostic message containing the offending line. Consequently, the output is exactly one line, not the entire file content.

Raises an unhandled exception.

Why wrong: The raise statement is executed inside a try block, and the corresponding except clause catches the exception object. Once caught, the exception is converted into a printed message and the program completes normally with exit code 0, so no traceback propagates to the interpreter. Therefore, the exception is fully handled and should not be described as unhandled.

Prints all lines containing 'ERROR'

Why wrong: While the condition selects lines that contain "ERROR", the action taken on the first match is to raise an exception, not to print the line and continue. The raise aborts the for loop, so any later matching lines are never examined. The sole output is the exception's string representation of that first ERROR line, not a collection of all ERROR lines.

Open the file without using a context manager and manually close it after each read.

Why wrong: Manually closing and reopening the file without a context manager adds no protection against descriptor invalidation; it merely replaces Python's deterministic resource management with error-prone manual calls to close(). If an exception occurs before the manual close, the file descriptor is leaked, and the code still needs to catch OSError to know when to re-open anyway. This approach neither prevents the stale descriptor problem nor simplifies error recovery, whereas a `with open()` block guarantees cleanup even when OSError is raised, making it the safer and more maintainable choice.

Increase the read buffer size to 4096 bytes to reduce the number of read operations.

Why wrong: Increasing the read buffer size to 4096 bytes only reduces syscall overhead by amortizing reads, but does nothing to prevent a file descriptor from becoming invalid when an external process replaces or truncates the file. The OSError (e.g., EIO or EBADF) arises from the underlying inode being unlinked or the descriptor being closed out from under the process, which is independent of how many bytes are requested per read. Even with a larger buffer, a subsequent read on the stale descriptor will still raise the same exception, making this a performance-tuning measure rather than a robustness fix.

Use file locking (e.g., fcntl.flock) to coordinate access with the external process, and re-open the file if a lock cannot be acquired.

Why wrong: File locking is only effective if the external process also uses locks; otherwise, it does not prevent the file descriptor from becoming invalid. Moreover, locking can lead to deadlocks and does not handle cases where the file is replaced.

Open the CSV file, import the csv module, create a csv.reader object, iterate over the reader to access each row, close the file.

Why wrong: This fails because the csv module is referenced before it has been imported; when the script tries to create a csv.reader object, Python raises a NameError since the name 'csv' is not yet defined. Opening the file first is not only unnecessary but also risks leaving the file handle open if the subsequent import or reader creation fails. The import must be the very first step, before any file handling, because the csv.reader function is required to parse the file.

Import the csv module, create a csv.reader object, open the CSV file, iterate over the reader to access each row, close the file.

Why wrong: The csv.reader constructor requires an open file object as its first positional argument, so calling it before any file has been opened raises a TypeError because there is no file object to pass. Even if a placeholder were supplied, a real file handle returned by open() is necessary for reading rows from disk. Opening the CSV file must precede reader creation because the reader is designed to wrap an existing file object and parse its lines into fields.

Import the csv module, open the CSV file, iterate over the reader to access each row, create a csv.reader object, close the file.

Why wrong: Iterating over 'the reader' before the csv.reader object has been created raises a NameError because the variable 'reader' has not been assigned yet, so Python has no reference to iterate over. Moreover, while the file was opened, directly iterating the file object would yield raw lines, not parsed CSV fields. The reader must be created from the open file first, and only then should you iterate over that reader to access the parsed rows.

os: Provides access to some variables used or maintained by the interpreter.

Why wrong: This description actually defines the sys module, not os, because sys exposes interpreter-specific objects such as sys.argv (command-line arguments), sys.path (module search path), sys.version, and sys.exit(). The os module, by contrast, deals with the operating system environment rather than the Python interpreter's internal state. While os.environ does give access to environment variables, that is an OS feature, not something 'maintained by the interpreter'.

sys: Provides functions for working with dates and times.

Why wrong: This description belongs to the datetime module, which supplies classes such as datetime.date, datetime.time, datetime.datetime, and timedelta for working with dates and times. The sys module, in contrast, does not provide any date or time functionality; instead it focuses on interpreter state. A common confusion arises because time-related functions like time.time() live in the separate time module, further distinguishing sys from date/time handling.

json: Provides support for regular expressions.

Why wrong: Regular expression support in Python is provided by the re module, which offers functions like re.search(), re.match(), re.findall(), and re.sub() along with compiled pattern objects. The json module has nothing to do with pattern matching; its sole purpose is JSON serialization and parsing. This confusion likely originates from the fact that both modules are commonly used in data processing, but their responsibilities are entirely distinct: re parses text patterns, while json parses structured data interchange formats.

try: read_file() except (UnicodeDecodeError, OSError): pass

Why wrong: Catching a tuple of UnicodeDecodeError and OSError then silently passing is dangerous because it groups two unrelated failure modes: a file that cannot be decoded versus a file that cannot be read due to a missing path or permissions. Using pass discards the exception entirely, so there is no log record to indicate why a file was skipped, which is poor operational practice. Moreover, catching OSError here is unnecessary when the goal is logically to skip only corrupt encoded files, and it could hide real I/O problems.

try: read_file() except Exception: log.warning('Skipping file')

Why wrong: Using except Exception is far too broad for this use case because it intercepts every normal runtime exception, including programming mistakes like TypeError, KeyError, or ValueError, and masks them as 'skipped file' warnings. That means a genuine bug in read_file() would be hidden behind a misleading log message, making it nearly impossible to recognize and fix the actual error. Also, a blanket-except handler can interfere with cleanup or context-manager behaviors, and it captures errors that have nothing to do with decoding user uploads.

try: read_file() except UnicodeEncodeError: log.warning('Skipping file')

Why wrong: UnicodeEncodeError is raised when Unicode text is being converted into bytes—for example, during str.encode() or when writing to an output stream with a specific encoding—not when reading raw bytes and decoding them into text. Since read_file() in this context is reading a user-uploaded file, the failure point is decoding those bytes into a string, which raises UnicodeDecodeError instead. Although the two exceptions are siblings under UnicodeError, catching the encode variant would leave the actual decode failure completely unhandled, causing the program to crash.

def __exit__(self, exc_type, exc_val, exc_tb): self.connection.commit()

Why wrong: Calling self.connection.commit() unconditionally in __exit__ means the transaction is committed even when an exception has been raised inside the with block. This can persist incomplete or invalid data, breaking atomicity. The parameters exc_type, exc_val, and exc_tb are ignored; commit should only occur when no exception is pending, so the code must inspect exc_type to distinguish success from failure.

def __exit__(self, exc_type, exc_val, exc_tb): self.connection.rollback()

Why wrong: Calling self.connection.rollback() unconditionally discards all changes made within the with block, even when no exception occurred. This defeats the purpose of a database session by ensuring that successful operations are never persisted, effectively making every transaction a no-op. The rollback should happen only when exc_type is not None, not for every normal exit.

'wb'

Why wrong: While 'wb' does permit writing binary data, opening with this mode destroys any existing content by truncating the file to zero length before the first write. If the developer needs to preserve existing file contents and simply append new binary data, this mode is inappropriate. It is only usable when overwriting the entire file from the beginning is acceptable.

'rb'

Why wrong: The 'rb' mode opens the file for binary read-only access; any attempt to write produces an io.UnsupportedOperation error. It does not create a file if it does not exist and simply fails with FileNotFoundError. Therefore, it cannot satisfy the requirement to write binary data.

'wb+'

Why wrong: Although 'wb+' permits both binary reads and writes, it opens by truncating any existing file to zero length, just like 'wb'. This means any previous data is lost immediately, making it unsuitable if preservation or appending is intended. The extra read permission does not compensate for the destructive truncation.

except ValueError as e: log.error(e); return None

Why wrong: Returning `None` turns an exception into a normal, successful return, so the caller has no signal that a failure occurred. The exception is handled and swallowed, meaning any code that expects a valid result may silently receive `None` and potentially fail later with a confusing attribute error. This violates fail-fast principles—the error is logged, but the program's state is not preserved, and the exception's propagation is deliberately cut short.

except ValueError as e: log.error(e); raise ValueError('New')

Why wrong: Raising `ValueError('New')` constructs a brand-new exception object, discarding the original exception's message, traceback, and any payload. Unless chained with `from e`, the new exception is not linked to its cause, so debugging the root issue becomes much harder. Even if the type is the same, the original context is lost, which can mislead developers who only see the new message and never know the underlying error that triggered the handler.

except ValueError as e: log.error(e); pass

Why wrong: Using `pass` in the `except` block silently swallows the exception with no logging and no propagation, making the failure completely invisible to the caller and to logs. This is the most dangerous option because it not only changes control flow but also provides zero diagnostic record, so an intermittent error may go unnoticed for a long time. The program continues as if nothing happened, which can lead to corrupted state or unobserved data loss far downstream from the actual fault.

file = open('data.txt'); # read; file.close()

Why wrong: Calling `file.close()` after the read only works when execution reaches that line; if an exception is raised inside the `# read` section, the method is skipped and the file remains open until the object is garbage-collected or the process exits. This approach is not exception-safe and can lead to resource leaks in long-running applications, so it fails the 'proper resource cleanup' requirement.

file = open('data.txt'); if not file.closed: file.close()

Why wrong: Checking `file.closed` only after the read completes does not protect against exceptions raised during the read, because the `if` line is never reached when an exception occurs. Moreover, `file.closed` is always `False` for a successfully opened file at that point, making the condition a redundant tautology; the explicit `close()` would be needed regardless, but placing it after the read still leaves no exception safety. Thus this offers no benefit over a simple `close()` and lacks the guarantee of a context manager.

The order of except clauses does not matter because only one will match.

Why wrong: The order of except clauses is significant because Python evaluates them from top to bottom and executes the first matching handler; it does not search for the 'best' match. If a broader exception type like `except Exception` appears before a more specific one like `except ValueError`, the broader clause will catch the ValueError, and the narrower clause will never run. This is a common source of bugs, so specific exceptions must always precede more general ones.

An else block can be used without any except blocks in a try statement.

Why wrong: In Python's grammar, an `else` clause in a `try` statement is only valid when at least one `except` clause is present; a `try` block followed directly by `else` is a syntax error. The grammar defines `try1_stmt` with a mandatory nonempty sequence of `except` blocks before the optional `else` and `finally`, while `try2_stmt` allows `try`...`finally` but no `else`. Therefore, you cannot use an `else` block without first having an `except`.

The else block in a try statement executes only if an exception was raised.

Why wrong: The `else` block in a `try` statement executes only when the `try` block finishes without raising any exception; it is skipped if an exception is raised and handled by an `except` clause. Its purpose is to contain code that should run only on success, so that this code is not accidentally protected by the preceding `except` handlers. Thus, saying it executes only if an exception was raised is exactly backwards.

The code will print 'Lookup' because LookupError is more general.

Why wrong: The first matching except executes; IndexError matches before LookupError.

If the code were accessing a dictionary key, LookupError would catch KeyError.

Why wrong: This statement is not about the given code; it refers to a different scenario. The question asks for statements about this specific code snippet, so D is incorrect.