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 the exception and re-raise the same exception.

  Why it's wrong here

  Catching and re-raising the same exception merely forwards the original traceback and message unchanged. If the pipeline's top-level handler is not secure, sensitive internals such as file paths, database queries, or model parameters may be exposed to the client. It also forfeits the chance to add contextual information and does not satisfy the goal of decoupling internal failure details from external responses.

• ✗

  Catch the exception, log it, and suppress it silently.

  Why it's wrong here

  Silently suppressing an exception after logging creates a false sense of reliability because the pipeline may appear to complete while records are actually missing or corrupt. Operators are unlikely to monitor raw logs in real time, so critical failures can go unnoticed until downstream consumers report bad data. Swallowing exceptions also violates the fail-loud principle, as a partially processed dataset is often worse than an explicit error.

• ✓

  Catch the exception, log the full traceback, then raise a custom generic exception.

  Why this is correct

  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.

• ✗

  Catch the exception and print it to the console.

  Why it's wrong here

  Printing the exception to the console places unredacted error details where end users or shared log viewers may unintentionally see them, creating an information-disclosure risk. Console output typically contains only the exception message, not the full stack, so developers lose diagnostic value. It also bypasses standardized logging facilities, making errors harder to correlate, filter, and alert on compared with a proper logging framework.