Structured Error Handling and Propagation Quiz Quiz

Challenge your understanding of structured error handling, error codes vs. exceptions, adding context, managing retries, and resource cleanup in robust software systems.

1. Propagating Errors with Exceptions

   When a function detects an unexpected error and uses an exception to signal it to a caller, what is the main advantage over returning an error code?

   1. Exceptions always execute faster than error codes.
   2. Exceptions guarantee that resources are freed automatically.
   3. Exceptions separate error-handling logic from business logic more cleanly.
   4. Exceptions cannot be missed by the caller.
   5. Exceptions require less code than error codes in all cases.

2. Error Context Enhancement

   Given a scenario where an error occurs deep within a series of function calls, what technique best improves diagnosability when the error is propagated?

   1. Returning only generic error codes from each function.
   2. Wrapping the error with contextual information at each level.
   3. Logging errors only at the highest level.
   4. Using ambiguous return values to hide specifics.
   5. Silently discarding errors to avoid confusion.

3. Error Codes vs. Exceptions

   Which of the following is a significant challenge when using error codes instead of exceptions for error propagation in large codebases?

   1. Error codes improve type safety in all languages.
   2. Error codes automatically escalate to the highest level.
   3. Error codes prevent any form of resource leakage.
   4. Error codes provide stack traces on their own.
   5. Forgetting to check the return code at every function call.

4. Retry Logic Placement

   In implementing automatic retries for transient failures, where should retry logic ideally reside to maximize code reuse and clarity?

   1. In a dedicated wrapper or middleware around the operation.
   2. Statically coded within each resource object.
   3. Spread across helper scripts with no centralized control.
   4. Inlined within the main application loop for all operations.
   5. Inside every individual function that makes an external request.

5. Resource Cleanup with Exceptions

   When handling exceptions, what construct or technique is most reliable for ensuring that resources such as files or locks are always released?

   1. Relying on garbage collection alone for all resources.
   2. Skipping cleanup if the program is about to exit.
   3. Placing cleanup code randomly in the function body.
   4. Using a 'finally' block or a destructor-like cleanup mechanism.
   5. Only releasing resources when no exceptions are raised.

6. Adding Context to Errors

   When rethrowing an error after catching it, which practice best preserves detailed information for troubleshooting?

   1. Ignoring the stack trace to avoid confusion.
   2. Appending contextual data about the current state before propagating.
   3. Masking the error code with a generic one.
   4. Suppressing the error message for security.
   5. Converting the exception to a warning.

7. Idempotency in Retry Logic

   Why must operations be idempotent when implementing automatic retries after errors such as timeouts?

   1. Because idempotency enforces input validation.
   2. Because non-idempotent operations cannot fail.
   3. To ensure retries are faster than initial attempts.
   4. So that errors are automatically logged.
   5. To prevent unintended effects from repeated executions.

8. Structured vs. Unstructured Error Handling

   Which aspect best distinguishes structured error handling from unstructured error handling in complex software systems?

   1. Use of typed exceptions or return values with semantic meaning.
   2. Suppressing all errors unless fatal.
   3. Frequent use of global variables to signal errors.
   4. Printing error messages directly to the console.
   5. Ignoring function return values by default.

9. Exception Safety and Resource Ownership

   In code that acquires multiple resources, what principle helps avoid leaks if an exception interrupts the sequence?

   1. Polling resource states instead of releasing.
   2. Delaying exception handling for performance.
   3. Immediate resource ownership transfer to a managing scope object.
   4. Only acquiring resources after error-prone operations.
   5. Deferring all acquisition to just before resource release.

10. Error Handling Granularity

    When deciding at what level to catch and handle exceptions, which strategy generally leads to the most maintainable code?

    1. Catching exceptions in the middle of the call stack regardless of context.
    2. Always catching and logging exceptions immediately at point of origin.
    3. Catching all exceptions globally and ignoring all details.
    4. Never catching exceptions, allowing uncontrolled program abort.
    5. Catching exceptions at the highest layer that can respond meaningfully.