Exceptions and File I/O practice questions

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

Why it fails: 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 it fails: 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 it fails: 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.

Set the __cause__ attribute in __init__.

Why it fails: __cause__ is for exception chaining, not message display.

Override __str__ to return a formatted string.

Why it fails: Exception already provides __str__ if message is passed to init.

Override __repr__ to return a detailed representation.

Why it fails: __repr__ is not used for displaying exception messages.

raise

Why it fails: 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 it fails: 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.

Prints all lines in the file.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 code will print 'Lookup' because LookupError is more general.

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

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

Why it fails: 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.

'rb'

Why it fails: Requires file to exist.

'w'

Why it fails: Creates new file if not exists.

'r'

Why it fails: Requires file to exist.

ERROR

Why it fails: Selected by matching the word 'ERROR' alone? Actually a line-oriented filter prints the full text of every line containing the pattern. The log line is exactly "ERROR: Disk full", so outputting only "ERROR" truncates the record and would require a substring-extraction mode such as grep -o, which the command does not use. Therefore this option is wrong.

INFO: Process started\nERROR: Disk full

Why it fails: This option incorrectly prepends the INFO line, which appears before the hit but does not satisfy the search condition. The filter evaluates each line independently: "INFO: Process started" has no "ERROR" substring, so it is skipped even though it is adjacent. Output is thus just the ERROR line, not a contiguous block of lines around the match.

ERROR: Disk full\nWARN: Memory high

Why it fails: Including the WARN line confuses the search result with everything after the match. The line "WARN: Memory high" has no "ERROR" substring and is separated by a newline from the hit; line-oriented selection does not automatically include subsequent non-matching lines. The command stops at the chosen lines, so only "ERROR: Disk full" appears.

f = open('file.txt', 'w'); f.write('data'); f.close()

Why it fails: This straightforward approach lacks any exception handling, so if f.write('data') raises an exception (e.g., disk full, permission error, or interrupted system call), the subsequent f.close() statement is skipped entirely. That leaves the file descriptor open and, more importantly, flushes none of the buffered data, so partially written or missing content can occur without any cleanup. In CPython, reference counting may eventually close the file when the object goes out of scope, but the timing is non-deterministic and the behavior is not guaranteed by the language, making this unsafe for production code.

f = open('file.txt', 'w'); try: f.write('data'); except: pass; f.close()

Why it fails: Here the bare except catches every exception, including KeyboardInterrupt, SystemExit, and MemoryError, which are not ordinary OSErrors and should normally propagate. More critically, the except block suppresses the write error itself, so the program silently continues even if the write failed because the disk is full—data loss is undetected. While f.close() will execute in the normal flow after the except, it is not guaranteed under all control-flow interruptions (e.g., if a signal arrives during the except block), and the swallowed exception prevents any logging or rollback that would indicate the file write did not succeed.

f = open('file.txt', 'w'); try: f.write('data'); finally: f.close()

Why it fails: This variant uses try/finally, so f.close() is guaranteed to execute whether f.write('data') succeeds or raises an exception; that makes it functionally correct for ensuring closure. However, it is more verbose and less idiomatic than the with statement, which the Python community and PEP 343 recommend for all resource management. Additionally, if both f.write() and f.close() raise exceptions, the exception from f.write() is lost because the exception from f.close() propagates, whereas the with statement handles cleanup in a way that preserves and chains the original exception, giving more debugging context.

ValueError

Why it fails: ValueError is unrelated to file I/O errors.

FileNotFoundError

Why it fails: This is the exact exception, but the question asks for a type that can handle it, and OSError is broader.

IOError

Why it fails: IOError is an alias of OSError in Python 3, but it's deprecated.

True

Why it fails: True would be the output only if the try block executed successfully and the code reached an explicit print(True) or an expression evaluating to True. But when the file cannot be found, the open() call raises an exception before any such print statement is encountered. Because the except clause fails to catch the raised exception, the program never continues to the line that would output True; instead, the unhandled exception triggers a traceback and the program errors out.

False

Why it fails: False would require the program to reach a print(False) or an expression that evaluates to False, typically after a successful operation or after the exception is caught by a matching handler. Here, the missing-file exception is not caught by the except clause, so the normal flow of execution is interrupted and jumps straight to the interpreter's error reporting. Consequently, the user sees a traceback and an error message, not the literal output False.

None

Why it fails: None could be displayed if the code executed a print statement with no argument or printed the result of a function that returns None, such as print(None) or print(some_none_returning_func()). In this scenario, the try block raises an unhandled exception—the file does not exist—and the except clause does not handle it, so the execution never reaches any print statement. The interpreter instead outputs an exception traceback, which is an error, not the Python value None.

None

Why it fails: None is the return value of a function or expression that produces no value, but here the code explicitly calls print() with the string "False". The print function always outputs its argument's string representation, not None. Since an exception occurs, the except branch prints False, not None.

True

Why it fails: "True" would be output only if the try block completes without raising an exception and the else clause (if present) executes. Since the code raises an exception during the try block, control jumps to the except block, skipping the else and any True output. Therefore True is not printed.

Error

Why it fails: The code does not produce an unhandled exception because the try-except structure catches the exception. In Python, an unhandled error would terminate the program with a traceback, but here the except block explicitly handles the exception and prints "False". Thus "Error" is not the output.

The function returns None.

Why it fails: A function returns None only when control reaches the end of the function with no explicit return value, or when a bare return statement is reached. In this code, the finally block raises NameError before control can fall off the end, so the function never completes normally. The exception propagates to the caller instead of yielding a None return value, making this option incorrect.

A FileNotFoundError is raised and not caught.

Why it fails: The FileNotFoundError raised by open() is not uncaught; the except FileNotFoundError handler intercepts it and runs its body. The error that ultimately escapes the function occurs later, in the finally block, where f.close() tries to reference the never-assigned variable f. This NameError supersedes the already-handled FileNotFoundError, so the exception reaching the caller is not FileNotFoundError.

The file is created and then closed.

Why it fails: open('data.txt', 'r') opens the file in read mode, and read mode does not create a missing file; only write or append modes would create a new file. Moreover, even if a file object existed, f.close() could not succeed here because the finally block raises NameError before the close call executes. This option incorrectly assumes the open mode creates the file and that the finally block successfully closes a non-existent handle.

123

Why it fails: The value 123 is successfully read and converted, but there is no print or other operation that sends it to standard output. Merely calling int(f.read()) or assigning the result to a variable doesn't produce console output; output requires an explicit print/write statement. Thus 123 is not displayed.

Error: invalid literal for int()

Why it fails: This exception would occur if f.read() yields a string that cannot be converted to an integer, such as an empty file or non-numeric text. Since data.txt contains exactly "123", the conversion is valid, and int() also tolerates surrounding whitespace or a trailing newline. Therefore no ValueError is raised during conversion.

Error: [Errno 2] No such file or directory

Why it fails: This OSError/FileNotFoundError would be raised at the open() call, before any reading or conversion happens, and only if data.txt does not exist. The question explicitly says data.txt exists and contains 123, so the file opens successfully. The error is not related to the file's content or the int() conversion.

No output

Why it fails: No output is impossible here because the missing-file lookup raises an OSError subclass (specifically FileNotFoundError) while the file is being opened, and the except OSError block intercepts that exception. Consequently, the handler's print('OS error') statement must run, which produces one line of output. For 'No output' to happen, the open would have to succeed or the exception would have to be silently swallowed, neither of which matches the displayed code.

Traceback with FileNotFoundError

Why it fails: A traceback ending in FileNotFoundError occurs only when the exception escapes unhandled, but here the except OSError clause catches the failure before Python reaches the default traceback handler. Because FileNotFoundError inherits from OSError, the matching exception handler is selected and the program prints the literal message 'OS error' instead. The code does not re-raise the exception or omit the except block, so no traceback is displayed.

File not found

Why it fails: 'File not found' is not the output because the program never prints the exception object or its message; it prints a hard-coded string from the except block. If the code had been written as except FileNotFoundError as e: print(e) or print(e.strerror), the output might include 'No such file or directory' or similar, but not the title-case words 'File not found'. The exhibit's handler deliberately replaces the original OS detail with the fixed label 'OS error'.

A C D

Why it fails: Choosing A, C, and D would require the first, third, and fourth print statements to execute while the second is skipped. In the exhibit, the condition guarding the third print statement evaluates to False, so C is never produced. Including C adds an output line that cannot appear with the given data, making this option incorrect.

A

Why it fails: Selecting only A overlooks the fact that after the first print statement executes, the program continues and the condition for the fourth print statement also evaluates to True. The exhibit clearly shows D being printed later in the same execution path. Stopping at A incorrectly assumes an early exit that does not occur in the code, so the answer is incomplete.

B D

Why it fails: This combination incorrectly substitutes B for A, even though the second condition evaluates to False and the first condition evaluates to True in the exhibit. It also misses the A that is printed at the start of the execution. While D is correctly included, the presence of B and the absence of A make this set incompatible with the actual program flow.

PermissionError

Why it fails: 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 it fails: 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 it fails: 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.