Exercise 3: The Genuine Tradeoff of Centralizing Error Handling in DECLARATIVES — Possible Solution ==================================================================== WHAT DECLARATIVES GENUINELY BUYS A PROGRAM This chapter's own material frames DECLARATIVES as the fix for "the real repetition problem" - one centralized paragraph, declared once, that automatically catches every non-successful FILE STATUS on a given file, no matter which individual statement caused it. This genuinely removes the need to write and maintain the same handling logic at every single READ, WRITE, REWRITE, or DELETE against that file, and it genuinely guarantees no I/O statement can accidentally be left with zero error handling at all - the file-level coverage applies everywhere automatically. WHAT INLINE, PER-STATEMENT HANDLING GENUINELY OFFERS INSTEAD Handling INVALID KEY or AT END separately, at each individual statement, means the handling code sits at the exact point where the program knows precisely what it was just attempting - which specific customer was being looked up, which specific record was being written, what the program was about to do next if that operation had succeeded. This chapter's own earlier examples (Chapters 1 and 3, for instance) show exactly this kind of localized handling, each response tailored to what that specific statement was trying to do. WHAT CENTRALIZED HANDLING GENUINELY LOSES BY COMPARISON A single DECLARATIVES paragraph covering an entire file has no direct knowledge of which specific statement, or which specific real business context, triggered the error it's now handling. This chapter's own worked example reacts to code 23 with a generic "RECORD NOT FOUND" message - genuinely correct, but the same generic response fires whether the missing record was for a random balance check, a validation lookup, or any other real reason a program might have attempted that read. A response tailored to what the program was specifically doing at that moment isn't naturally available inside one shared, file-wide paragraph the way it would be at the exact point of an inline INVALID KEY clause. WHY THIS IS A GENUINE TRADEOFF, NOT A STRICT IMPROVEMENT Centralizing handling in DECLARATIVES trades away per-statement context and fine-grained, operation-specific responses in exchange for guaranteed coverage and far less repeated code. Keeping handling inline at each statement trades away that repetition and coverage guarantee in exchange for a response that can be precisely tailored to exactly what the program was attempting at that specific point. Neither approach is simply better in every real case - the right choice depends on whether a file's various operations genuinely need different, context-specific responses, or whether one consistent real response is genuinely appropriate everywhere that file is touched. ANSWER: Moving CUSTOMER-FILE's own error handling into one DECLARATIVES section genuinely eliminates repeated handling code and guarantees every I/O operation against that file is covered automatically, but it trades away the ability to give each individual statement its own precisely tailored, context-specific response - the centralized paragraph reacts the same way regardless of which specific operation or real business situation triggered the error. Handling each statement's own INVALID KEY or AT END clause inline keeps that precise, per-statement context available, at the real cost of repeating similar handling logic at every call site and risking one statement being left without any handling if it's ever forgotten. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly identifies both real sides of the tradeoff (guaranteed, repetition-free coverage vs. precise, context-specific per-statement response) rather than presenting DECLARATIVES as an unconditional improvement, and grounds both sides in this chapter's own material and earlier chapters' own inline-handling examples.