CCNA Exceptions and File I/O Questions

Opening with 'rb' returns a file object whose .read() method produces a single bytes object containing the entire file content. If the path points to a directory, calling .read() raises precisely IsADirectoryError (an OSError subclass on POSIX), and the narrowly-scoped except IsADirectoryError catches only that case, returning b''. The with block guarantees the file object is closed even if the read fails, and no other OS errors (such as PermissionError) are swallowed.

The read() method, called with no arguments, reads from the current file position to EOF and returns the entire remaining content as a single string in text mode, or a single bytes object in binary mode. It is the only method among the options that returns the whole file content as one undivided value, which is exactly what the question asks for.

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.

This is the canonical EAFP implementation: it attempts the division inside a try block and catches only the exact exception that signals division by zero. ZeroDivisionError is a subclass of ArithmeticError and is raised whenever a numeric denominator evaluates to zero, so returning None is a clean and specific fallback. Any other exception (such as TypeError for incompatible operands) is deliberately allowed to propagate, preserving the caller's ability to debug the real error.

A single except clause can catch multiple exception types by passing a tuple, e.g., `except (ValueError, TypeError) as e:`. The raised exception is matched against the tuple using `isinstance()`, so any exception that is an instance of one of the listed types (including subclasses) is handled. Parentheses are mandatory because the syntax requires a literal tuple; writing `except ValueError, TypeError:` is invalid in Python 3. This lets you group unrelated exceptions that need identical handling into one clause.

`exec('1/0')` raises a `ZeroDivisionError`, caught by the bare `except`, so `error` prints. The `else` block runs only when no exception occurs, so `no error` is skipped. The `finally` block always executes, printing `done`. Output is therefore `error done`.

When a file is opened in text mode with an explicit encoding, reading bytes that do not form valid sequences for that encoding raises UnicodeDecodeError, a subclass of UnicodeError. In this scenario the declared encoding is UTF-8, so invalid UTF-8 byte sequences trigger this exception during readline(). Handling it allows the program to log the offending position or fall back to a different decoding strategy.

The bare `raise` inside the `except` block re-raises the identical exception object that was caught, preserving its full traceback, original message, and any associated attributes. Logging first allows the current layer to record the failure, then the same exception continues propagating up the call stack for the caller to handle. This is the canonical way to log-and-rethrow without altering the exception's identity or stack trace, making the failure visible at every layer that observes it.

A finally block executes as the try statement unwinds, whether the try block completed normally or raised. In this scenario, when the write fails, control transfers to finally before the exception continues to the caller, so both file handles can be closed there. This guarantees cleanup without suppressing the original exception, which is the intended behavior.

FileNotFoundError is a concrete subclass of OSError, raised when a required file or directory does not exist. Because it inherits from OSError, it is caught by an except OSError handler, yet it is distinct from PermissionError, which occurs when the item exists but access is denied. This makes it one of the three options in the OSError hierarchy.

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.

Mode 'w' opens the file for writing, creating the file if it does not exist and truncating it to zero length if it does, thereby discarding all previous contents. This exactly matches the need to write a complete, fresh set of data: any existing content is erased before the first write, ensuring that the final file contains only the current output with no stale data.

The correct output is None because `int("abc")` raises a ValueError, which is caught by the matching `except ValueError` block. That handler assigns the result variable to None, and when the code later prints that variable, Python displays the string representation of None (i.e., "None").

The `finally` block guarantees execution after the `try` block completes, whether an exception is raised, caught, or the block exits via `return`, `break` or `continue`. This satisfies the stem's requirement for a statement that is always true, since only `finally` provides unconditional cleanup semantics in Python.

This is the correct statement. Calling `readlines()` reads every line of the file into a list of strings, meaning the entire file content is loaded into memory at once. For large log files, this can consume a massive amount of RAM, potentially causing the program to slow down or crash with a MemoryError. A more memory-efficient approach is to iterate directly over the file object (`for line in f:`), which reads one line at a time lazily, keeping the memory footprint low regardless of file size.

The with statement is a context manager that calls close on the file object when the block exits, whether normally or through an exception. It replaces the manual try/finally and close calls with a single readable construct. This is the idiomatic Python 3 approach and directly satisfies the reviewer's request for guaranteed closure.

This is the classic time-of-check-to-time-of-use (TOCTOU) race: in a multithreaded server, two threads can evaluate `os.path.exists(path)` at nearly the same instant, and then one thread may delete or replace the file before the other actually opens it. The check and the use are not atomic, so LBYL gives a false sense of safety. EAFP, by contrast, wraps the open itself in a try-except, handling the failure exactly when it occurs and eliminating the gap.

int('abc') invokes Python's integer constructor on the non-numeric string 'abc'. Since the string does not contain a valid integer literal—even after stripping surrounding whitespace or handling an optional sign—the conversion fails, raising a ValueError with the exact message "invalid literal for int() with base 10: 'abc'". This is the precise exception and message that the exhibit/question targets, making this the correct snippet.

The `with` statement invokes the context manager's `__exit__` method on block exit, and for file objects that method calls `close()`. This makes file closure deterministic and automatic, even if the block ends early due to a `return`, `break`, or `continue`. A bare `open()` without `try/finally` would not provide this guarantee.

Catching FileNotFoundError explicitly handles the missing-file condition while allowing execution to continue, which is the idiomatic Python approach. It satisfies the graceful-continuation constraint precisely, unlike broad exception handling or pre-checking with os.path.exists, which introduces race conditions.

An exception inside `process_data(data)` unwinds the stack before `f.close()` executes, leaving the file descriptor open until garbage collection reclaims it. That satisfies the stem's leak constraint: `close()` is skipped, so the descriptor is not released deterministically. A `with` statement or `try/finally` guarantees closure.

The with statement is semantically equivalent to a try/finally block because the interpreter guarantees that __exit__ is invoked when the block ends, whether it finishes normally or an exception is raised. This ensures cleanup code always runs, just as finally does after try. The key difference is that with also calls __enter__ at the start to initialize the resource, making it a structured way to pair setup and teardown.

The else clause is part of a try/except/else/finally compound statement. It executes only when the try block completes without raising any exception, meaning control flows to else immediately after the last statement in try. If an exception occurs, else is skipped and control jumps to a matching except handler instead. This makes else ideal for code that should run only on success, such as logging successful completion or proceeding with a computed result.

Because neither data.txt nor backup.txt exists, the outer try raises FileNotFoundError, and then the inner try also raises FileNotFoundError. The inner except FileNotFoundError block catches this second exception and executes print('No file found'), making that literal string the exact output displayed by the program.

This is the correct approach because it deliberately catches only UnicodeDecodeError, which is the exception raised when reading and decoding bytes containing invalid UTF-8 or another specified codec. By logging a warning and doing nothing else, the handler reports the problem while allowing the surrounding loop to move on to the next uploaded file. More specific handlers like this leave unrelated exceptions—such as OSError or file-system errors—free to propagate, preserving their diagnostic value.

Using `from None` in a `raise` statement sets the `__suppress_context__` attribute of the exception to `True`. When the TypeError propagates, Python's default exception handler checks this flag and, because it is true, omits the implicit display of the original ValueError and its traceback. The final output therefore contains only the TypeError, either in the interactive shell or in a captured traceback.

IsADirectoryError is raised when the operating system reports that a path expected to be a regular file is actually a directory. Catching it by name lets the script log a specific message for that condition while allowing FileNotFoundError to fall through to its own handler. This directly satisfies the requirement to distinguish the two failures.

This is the correct form for explicitly chaining a new exception to an existing one. The `from original_exception` clause makes Python assign the original to the new `ValueError`'s `__cause__` attribute, causing the traceback to present the original as the direct cause of the new exception. This preserves the debugging information from the original failure while still allowing a distinct exception type to be raised.

This is the canonical pattern: the library base class derives from Exception, so all library errors are ordinary, catchable exceptions; the specific subclasses then derive from that base class. Code catching LibraryError will also catch FileError and ParseError, while code can still catch either refined type independently. This gives a consistent API and lets the library evolve by adding new specific errors without breaking callers that rely on the base type.

The mode string 'wb' is the correct Python file mode for binary writing. The first character 'w' specifies the operation (write), and the second character 'b' explicitly selects binary mode rather than text mode. This mode both creates the file if it does not exist and truncates it to zero length if it does, allowing you to write raw bytes without any encoding or newline translation.

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.

ValueError is a built-in exception and belongs to the Exception hierarchy, directly under Exception (and ultimately under BaseException). It is raised when a function receives an argument of the correct type but an inappropriate value—for example, int('abc') raises ValueError because the string cannot be converted to an integer. This distinguishes it from TypeError, which is for wrong types, and from other built-in exceptions that signal different error conditions.

This is correct because the code reads the configuration value and converts it to an integer using int() (or a ConfigParser getint() call). The integer 8080 is then passed to print(), which displays the number without quotes. Since the conversion succeeds, the output is exactly the integer 8080.

Invalid JSON is correct because the file exists and is readable, but its content cannot be parsed by json.load() or json.loads(). The json module raises json.JSONDecodeError, a subclass of ValueError, when the data does not conform to JSON syntax. The program's except block catches this exception, confirming the specific outcome is "Invalid JSON" rather than any file-system error.

OSError is the base class for I/O failures such as a device being unplugged, and read() raises it when the underlying read fails. Catching OSError around the read allows a bounded retry loop for this transient hardware problem, while still letting unrelated errors propagate. Because FileNotFoundError and PermissionError inherit from OSError, the handler should inspect errno or use a narrower subclass if those must be handled differently.

The replace error handler substitutes the Unicode replacement character U+FFFD wherever the decoder encounters an invalid sequence. The resulting string is valid and the read does not raise, so the tool can search for U+FFFD to count and locate suspect regions. This matches the requirement to continue processing while recording that replacement occurred.

KeyboardInterrupt is a true statement because KeyboardInterrupt is a direct subclass of BaseException, not of Exception. This design ensures that a KeyboardInterrupt triggered by Ctrl+C propagates outward even when code has a broad `except Exception:` handler. Catching it accidentally would prevent clean interruption and could leave the program in an inconsistent state, so it must be caught explicitly with `except KeyboardInterrupt` or a bare `except:`. The hierarchy deliberately places user-initiated termination outside the ordinary exception family.

Specific exceptions allow callers to catch precisely the conditions they can handle, using except clauses that match the exception type. Without distinct types, you would have to inspect messages or attributes, which is brittle and error-prone. Thus, raising a specific exception class is warranted when different error conditions require different handling, because the exception type itself becomes part of the API contract.

When entering a `with` block, Python calls the `__enter__` method on the context manager and assigns its return value to the `as` variable. Upon block exit, it always calls the `__exit__` method, which for a file object performs the actual closing operation. This pair of methods forms the core of the context manager protocol, and the `with` statement is simply a wrapper that guarantees both calls.

After reading 10 bytes (or characters, in text mode on most platforms) from the beginning of the file, the file pointer has advanced from offset 0 to offset 10. Calling tell() immediately after the read returns 10, which correctly reflects that new position in the stream. This is why 10 is the accurate answer: tell() always mirrors the exact number of bytes the read operation has consumed from the start.

finally is guaranteed to run during the unwinding of the try statement regardless of whether an exception occurred, was handled, or was replaced by a new exception inside a handler. This guarantee is what makes finally suitable for cleanup such as removing a temporary manifest file or releasing a lock.

The __exit__ method receives the exception type, value, and traceback, and its return value controls suppression. Returning False (or a falsy value such as None) means the exception is not suppressed and will propagate after __exit__ finishes. In this scenario the programmer wants the exception to propagate, so returning False after closing the file satisfies the requirement while still performing cleanup.

The 'with' statement works with any object implementing the context manager protocol, namely __enter__ and __exit__. This duck-typing behaviour means files, locks, sockets and custom classes all qualify, without requiring inheritance from a specific base class.

Calling f.read(4) on a binary file opened with mode 'rb' reads at most 4 bytes from the current file position, returning them as a bytes object. This is precisely the intended operation for reading a fixed-size chunk, which is essential when parsing binary formats that store data in fixed-width fields, such as integers or headers. The size argument caps the read length, so the file pointer advances by exactly the number of bytes actually read, and it handles end-of-file gracefully by returning fewer than 4 bytes.

After an exception is raised in the try block, Python finds the matching except clause and executes its body, printing "err". The finally clause then executes unconditionally as part of exception handling, printing "fin" after the except handler completes. Thus the full and correct output is "err fin".

FileNotFoundError is the specific built-in exception that Python raises when an attempt to open or access a file path cannot succeed because the path does not exist, typically with errno ENOENT. For a read operation, open(path, 'r') will immediately raise it if the file is not present before any other processing occurs. Because it is narrowly scoped, catching FileNotFoundError lets the developer provide exactly the right fallback—like creating the file or printing a meaningful message—without masking permission problems or unrelated OS failures.

Using the with statement is the idiomatic Pythonic solution because it leverages the context manager protocol: open() returns a file object whose __enter__ and __exit__ methods are invoked by with, guaranteeing that __exit__ calls close() even if the body raises an exception or encounters a return/break/continue. This automatically flushes buffered writes and releases the OS file descriptor deterministically at the end of the block. It also handles the case where open() itself fails by never entering the block, so no file object needs cleanup, and it expresses the intent of scoped resource management clearly.

The 'a' (append) mode opens the file for writing and places the file pointer at the end of the existing content, so every write extends the file without overwriting or truncating it. If the file is missing, Python creates a new empty file, matching the requirement to write new data while preserving what is already there. This is the only standard write mode designed specifically for adding to the end of a file.

This snippet is correct because it confines the error handling to exactly the condition the developer cares about: the file's absence. When the interpreter evaluates open('config.txt'), a missing config file raises a FileNotFoundError (a subclass of OSError), and that exception is caught and handled specifically. Other I/O problems, such as a permission denial or a path that is actually a directory, raise different OSError subclasses and are allowed to propagate, which preserves diagnostic accuracy.

When you write `raise NewException from None`, Python's exception-handling machinery sets `__suppress_context__ = True` on the new exception. This disables the automatic chaining that normally links the current exception to the one that was being handled, which would otherwise show as "During handling of the above exception, another exception occurred" in the traceback. As a result, only the final exception's traceback is displayed, and the original, caught exception is not shown as context, though it still exists internally.

SystemExit is the correct answer because it inherits directly from BaseException rather than from Exception. Unlike IOError, StopIteration, and ValueError—all of which are descendants of Exception—SystemExit bypasses the Exception class entirely. This deliberate design lets SystemExit (along with KeyboardInterrupt) propagate even when code catches Exception, so it is the only listed class that is not a subclass of Exception.

Since config.cfg exists but the process lacks the required read permission, the file's opening operation raises `PermissionError`. The corresponding `except PermissionError` clause catches it and executes its print statement, producing `'Permission denied'` as the program's visible output. This is the expected, handled outcome.

Calling traceback.format_exc() inside an except block returns a complete, pre-formatted traceback string that includes the exception type, message, and the entire call stack at the point of failure. This string can be directly written to a log file, sent to a monitoring system, or stored for later analysis, making it an appropriate technique for capturing exception details. Unlike print(e.args), it preserves the full execution context needed to diagnose the root cause.

NameError: name 'json' is not defined means Python could not find a binding for the name 'json' in any accessible scope. The json module is part of the standard library but is not automatically loaded; it must be brought into scope with an explicit import json statement. Since the script calls json.load(f) without having imported json, the name lookup fails at runtime. This is the classic missing-import error and is unrelated to the file's existence, content, or open mode.

The log explicitly shows "ValueError: ..." being raised. This is the precise exception type that occurred, so the appropriate handler is except ValueError. It is specific to the problem: a function received an argument of the right type but an inappropriate value. Catching this specific exception allows targeted recovery without swallowing unrelated errors.

OSError is the correct choice because it is the built-in exception class for all operating-system-related I/O failures—file not found, permission denied, disk full, or invalid file descriptor—and it deliberately excludes system-exiting exceptions like KeyboardInterrupt and SystemExit. Catching OSError lets the application handle upload failures gracefully without masking fatal interpreter or user-interrupt conditions. Since Python 3.3, IOError is an alias of OSError, so OSError is the canonical, forward-compatible name to use.

Opening /var/data/in.csv with the built-in open() function raises FileNotFoundError when the path does not exist, satisfying the stem's missing-file constraint. This OSError subclass carries errno ENOENT and is raised before any read occurs, so no other exception type applies here.

This is the canonical line-by-line iteration in Python. The file object is an iterator that yields one line at a time, reading from disk lazily as the loop advances, so only one line resides in memory at a time. This is memory-efficient and the recommended way to process text files sequentially.

When the user enters '0', int('0') returns 0 without error, so the try block proceeds to evaluate 10 / 0. This expression raises ZeroDivisionError, and Python matches it to the except ZeroDivisionError clause, causing 'Division by zero' to be printed. The output is exactly that message, demonstrating that an exception raised by an arithmetic operation is handled by its specific handler.

This is the correct output because the try block raises an exception that is caught by the except handler, which immediately prints 'error'. The else clause, which would print 'no error', is skipped because an exception was raised. The finally clause then unconditionally executes and prints 'done', producing exactly two lines: 'error' and 'done' in that order.

The 'w' mode opens the file for writing and truncates it to zero bytes if it exists, or creates a new file if it does not. This makes it the standard choice for write operations that should replace the entire contents of the file. It is the correct mode here because it permits immediate writing to the file with the expectation that prior content will be discarded.

'ab' opens a file for binary append: if the file exists, the file pointer is positioned at the end so all writes are appended after existing data, and the original content is never truncated. If the file does not exist, a new empty file is created automatically. This makes 'ab' the appropriate choice when writing binary data without destroying prior content.

"a\nb" is the exact output. The raise ValueError in the try block transfers control to the except ValueError handler, whose print('a') writes 'a' plus a newline. After that handler finishes, the finally block unconditionally runs and print('b') writes 'b' plus a newline, yielding two lines: first 'a', second 'b'.

ValueError is a built-in exception in Python, defined in the `builtins` module and raised when a function receives an argument of the correct type but an invalid value—for example, `int('abc')` or `math.sqrt(-1)`. It is deliberately distinct from `TypeError`, which covers type mismatches, allowing programmers to catch value-specific errors cleanly. As a built-in, it is always available without any import and is part of the core exception hierarchy.

Using `try: ... finally: f.close()` is the canonical Python idiom because the `finally` block is guaranteed to execute whether or not an exception is raised inside the `try` block. Unlike `except`, which only handles exception paths, `finally` runs on normal completion, on exception propagation, and even when a `break`, `continue`, or `return` is encountered in the `try` body. This ensures that the file descriptor is released deterministically, preventing resource leaks in both expected and exceptional control flows. It is the building block of context managers, where the `with` statement uses `__exit__` to achieve similar deterministic cleanup.

This is the recommended approach because it separates internal diagnostics from user-facing failure information. Logging the full traceback preserves the exact stack, exception types, and local context for developers, while raising a custom generic exception like PipelineProcessingError prevents sensitive implementation details from leaking. Using a custom exception also gives callers a stable interface for retry and alerting logic without coupling them to low-level I/O or network exceptions.

Correct syntax: parentheses form a tuple listing the two exception classes to catch. Python checks the raised exception against each class in the tuple and handles either FileNotFoundError or PermissionError in the same block. Because both derive from OSError, using this tuple is more precise than catching the parent class and avoids masking unrelated OSError subclasses.

FileNotFoundError is a precise subclass of OSError that Python's open() raises when the requested path cannot be found, including cases where a parent directory is missing or the path is a dangling symlink. By catching only this exception, the handler maps the specific 'missing resource' condition to send_404() and lets every other I/O problem—such as PermissionError—propagate or be handled elsewhere. This follows the EAFP (easier to ask forgiveness than permission) idiom and avoids the broader catch-all problems of checking existence beforehand.

Assigning the identifier as an attribute in the subclass __init__ makes it available on the caught exception object, which is how the worker logs it. Delegating to Exception.__init__ with the message populates the args tuple, and the inherited __str__ returns that message. Both requirements are satisfied by this design.

Exception is the standard, recommended base class for custom exceptions because it is the root of the ordinary error hierarchy, below BaseException but above all built-in exceptions meant for program-level failures. Deriving from it ensures your invalid-data exception is caught by generic `except Exception` handlers, supports chaining with `__cause__`, and clearly communicates that it is an application-level error. This is the convention described in Python's official documentation and followed by most libraries and frameworks.

FileNotFoundError is a built-in exception raised when a file or directory is requested but cannot be found at the specified path. It is a subclass of OSError and is specifically designed for missing-file scenarios, which is exactly the case when reading a configuration file that does not exist. In Python 3, it is the canonical exception for this situation, replacing the more generic IOError that was used in earlier versions.

This constructs a new instance of the custom exception class immediately before raising it, passing the string "invalid" into the constructor. That value is stored in the instance's args attribute and can be retrieved in an except block, making it the standard, readable way to raise a user-defined exception with diagnostic detail.