Exception Handling That Silently Loses Cases
A mortgage application process handles 1,800 items nightly. The process has a single global error handler at the top level that catches all exceptions, writes a line to a text log, and marks the queue item as Exception. Business users then manually re-key failed items from the log. Last month, 240 items were marked Exception but only 190 appeared in the log; 50 cases were never processed and were discovered only when customers complained. Investigation shows the missing 50 all failed inside a called object that performed a 'recover and continue' after a timeout, then returned a success status to the caller. The process also retries some items indefinitely because the retry counter is reset on each object call.
1. Explain why 50 cases were lost and why the retry logic never terminates.
Read the worked answer
Both failures stem from exception handling that suppresses rather than propagates error state.
The 50 lost cases. The called object caught the timeout, performed a recover-and-continue, and then returned success. From the caller's perspective nothing went wrong, so the item was marked complete. But the business transaction had not actually been performed. The top-level handler never fired, so nothing was written to the log. The result is a silent data-integrity failure: the queue says done, the customer says not done. This is the worst class of defect because it is invisible until an external party notices.
The endless retries. The retry counter is reset on each object call, so the count never accumulates across the item's lifecycle. Each call starts fresh, sees one failure, retries, resets, and loops. The item never reaches a terminal state, and the queue's retry limit is never consulted because the object handles the retry internally.
Root cause in both: error state is owned at the wrong level. Recovery decisions belong to the process that understands the business transaction, not to a low-level object that only knows a call timed out.
2. Redesign the exception handling so that failures are visible, bounded, and recoverable.
Read the worked answer
The redesign should establish clear ownership of error state at each layer:
Object layer. Objects should not swallow exceptions. On a timeout or application error, the object should raise a typed exception with context (action attempted, application response, timestamp) and let the caller decide. If a retry is genuinely safe at object level, it must be bounded and must raise on exhaustion. Never return success when the business action did not occur.
Process layer. Use a page-level recover block around each business transaction. On exception, capture the exception detail, increment a retry count stored on the queue item (not in a local variable), and decide: retry, mark exception, or mark failed. The retry count must persist across attempts so the limit is meaningful. Cap retries (e.g., three) and route exhausted items to a dedicated exception queue.
Queue design. Use distinct states: Completed, Exception (recoverable, needs review), Failed (terminal). Never mark an item complete unless the business outcome is confirmed. Add a post-condition check where feasible (e.g., confirm the case exists in the target system).
Logging. Log every exception with the item key and stage name to a structured store, not a flat text file, so counts reconcile. Add a nightly reconciliation report comparing items attempted, completed, and excepted, and alert on any gap. The 240-versus-190 discrepancy should have been caught by such a control on day one.