Error Handling Essentials: Exceptions, Cleanup, and Robust APIs Quiz

Test your understanding of structured error handling, the differences between exceptions and return errors, resource cleanup techniques, retry patterns with backoff and idempotency, and mapping errors to HTTP status codes. This quiz covers foundational concepts and best practices in reliable application design.

1. Distinguishing Exceptions and Return Errors

   When a function encounters an unexpected situation, which error handling method interrupts normal control flow automatically and requires a try/catch or similar block?

   1. Log message
   2. Warning
   3. Return error
   4. Exception

   Explanation: Exceptions raise errors that jump control flow to the nearest handler, so catching them often requires a try/catch or similar structure. Return errors, in contrast, are values returned that must be checked explicitly after each call. Log messages only report problems but do not interrupt flow, and warnings are typically informational without enforcing program structure changes.

2. Return Error Pattern

   Which of the following best describes a 'return error' pattern in function design?

   1. Throwing an exception automatically
   2. Returning a special error object or code as part of the function result
   3. Logging the error without returning anything
   4. Halting program execution immediately

   Explanation: The return error pattern involves a function returning an error value (such as a code or object) alongside the normal result, requiring the caller to check for errors. Halting execution is too drastic, exceptions involve control transfer rather than value returns, and logging alone does not communicate error information for handling.

3. Resource Cleanup Guarantee

   If a file is opened in a function and an error occurs during processing, which language construct ensures the file is always closed regardless of errors?

   1. continue statement
   2. break out
   3. immediately return
   4. finally or defer

   Explanation: The 'finally' or 'defer' construct is specifically used to guarantee cleanup actions like closing a file, regardless of whether normal execution or an error occurred. An immediate return can skip cleanup if not managed carefully, while continue and break are control statements that do not handle cleanup directly.

4. Retry Logic for Network Failures

   Which retry strategy helps prevent overwhelming a system when retrying failed network requests?

   1. Exponential backoff
   2. Short constant delay
   3. Immediate infinite retries
   4. Retry only once

   Explanation: Exponential backoff gradually increases the wait time between retries, helping reduce the risk of overwhelming the system and providing time for recovery. Immediate retries or constant short delays can worsen network congestion, and retrying only once may not be sufficient for transient failures.

5. Idempotency in Retry Operations

   Why is it important for operations like payment processing to be idempotent when implementing automatic retries?

   1. Because it makes requests run faster
   2. To ensure requests always fail
   3. So each retry uses random values
   4. So repeated requests do not cause unintended side effects

   Explanation: Idempotency guarantees that repeating the same operation will not lead to duplicated or harmful effects, which is crucial for actions like payments. The goal is not to make requests fail or faster, and randomness in retries does not address potential side effects from repeats.

6. HTTP 404 Error Mapping

   When designing an API, which HTTP status code should you use to indicate that a requested resource does not exist?

   1. 404 Not Found
   2. 201 Created
   3. 301 Moved Permanently
   4. 500 Internal Server Error

   Explanation: A 404 Not Found accurately signals that the requested resource could not be found. A 500 indicates server errors, 201 is used for successful resource creation, and 301 signifies that a resource has been moved, none of which are suitable for missing resources.

7. Catching All Unhandled Exceptions

   In structured error handling, where should you place a general exception-catching block to prevent program crashes from unforeseen errors?

   1. After variable declarations
   2. Inside every loop
   3. Directly after every statement
   4. At the outermost level of program execution

   Explanation: Placing a catch-all at the outermost level helps handle any exceptions not managed elsewhere, preventing unexpected crashes. Catch or error handling after each statement, after variable declarations, or within every loop is inefficient and burdensome.

8. Proper Error Message Design

   When returning error messages from an API, what is the best practice for user safety and clarity?

   1. Always use complex, technical jargon
   2. Include all internal technical information
   3. Return empty messages for security
   4. Provide generic yet helpful messages without exposing sensitive details

   Explanation: A helpful but generic error helps the user understand the issue without revealing sensitive system information. Detailed internal info or jargon can risk security and confuse users, while empty messages aren't informative.

9. Handling Return Values on Error

   If a function using the 'return error' pattern produces an error, what should the function's non-error return values typically be?

   1. Duplicate result
   2. Random data
   3. Default or null values
   4. Unrelated computed value

   Explanation: When an error occurs, return values should usually be set to defaults (such as null or zero) to indicate no meaningful result. Returning random, duplicate, or unrelated values would create confusion and make error handling less predictable.

10. HTTP 429 Too Many Requests

    Which HTTP status code is most appropriate for informing the user that they have exceeded a rate limit and should try again later?

    1. 503 Service Unavailable
    2. 429 Too Many Requests
    3. 200 OK
    4. 403 Forbidden

    Explanation: A 429 status code specifically indicates excessive requests and suggests rate limiting. A 200 is for success, 503 means temporary unavailability, and 403 is for permission issues, none of which accurately communicate throttling.