Exercise 2: A Plain READ CUSTOMER-FILE Hitting Code 23 With No INVALID KEY Clause of Its Own — Possible Solution ==================================================================== WHAT USE AFTER STANDARD ERROR PROCEDURE GENUINELY ESTABLISHES This chapter's own finding-box states this directly: declaring USE AFTER STANDARD ERROR PROCEDURE ON CUSTOMER-FILE genuinely runs the whole CUSTOMER-FILE-ERROR-PARA paragraph automatically whenever ANY I/O statement against CUSTOMER-FILE produces a non-successful real status - a READ, a WRITE, a REWRITE, any of them. This coverage applies across the entire program, not just to statements that happen to also carry their own explicit INVALID KEY or AT END clause. WHAT GENUINELY HAPPENS WHEN THIS PLAIN READ ENCOUNTERS CODE 23 Since this specific READ CUSTOMER-FILE has no INVALID KEY clause of its own, there's no local, per-statement handling code attached to it directly. But because the DECLARATIVES section's own USE statement already covers every I/O operation against CUSTOMER-FILE, the runtime genuinely detects the real code 23 result and automatically transfers control to CUSTOMER-FILE-ERROR-PARA - the same centralized paragraph this chapter's own example shows handling code 23 with a DISPLAY "RECORD NOT FOUND" message. WHY THIS DOESN'T CAUSE A CRASH OR LEAVE THE ERROR UNHANDLED The real reason this works safely is that the error handling was never actually tied to the individual READ statement in the first place - it's tied to the file itself, declared once in the DECLARATIVES section. A statement lacking its own local INVALID KEY clause isn't lacking error handling altogether; it's simply relying on the centralized handling this chapter's own DECLARATIVES section already established for every operation against CUSTOMER-FILE. WHY THIS IS EXACTLY THE REAL POINT OF USING DECLARATIVES AT ALL This chapter's own material frames DECLARATIVES specifically as a fix for "the real repetition problem" - repeating the same handling logic after every single I/O statement. This scenario demonstrates that solution working exactly as intended: a plain READ with no attached clause of its own still gets its real code 23 condition caught and handled, because the handling logic lives in one centralized place rather than needing to be copied onto every statement individually. ANSWER: Even though this plain READ CUSTOMER-FILE has no INVALID KEY clause of its own, the DECLARATIVES section's real USE AFTER STANDARD ERROR PROCEDURE ON CUSTOMER-FILE statement already covers every I/O operation against that file, so a real code 23 result automatically transfers control to CUSTOMER-FILE-ERROR-PARA, which displays "RECORD NOT FOUND" exactly as it would for any other statement's own code 23. This doesn't crash or leave the error unhandled because the error handling was never tied to individual statements in the first place - it's declared once, centrally, for the file itself, which is precisely the real problem DECLARATIVES exists to solve. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly explains that DECLARATIVES coverage applies at the file level rather than the individual-statement level, tracing exactly why a bare READ still gets handled, and ties the explanation back to this chapter's own stated motivation for DECLARATIVES.