ADVANCED COMPOSITING & RETOUCHING - Chapter 7, Exercise 3 Three Silently Wrong Files Out of 400: What Went Missing ==================================================================================== QUESTION: A batch script resizes and watermarks 400 product photos overnight. The next morning, three of the 400 output files are blank or wrong, with no error message anywhere. Using this chapter's own warning box, explain why this likely happened and what should have been built into the script to catch it. SOLUTION / EXPLANATION: This chapter's warning box describes exactly this scenario: batch processing multiplies Chapter 6's silent-failure risk, because a script written around the "happy path" - the expected, typical file - has no way to notice or react when one file out of many doesn't match those assumptions. With 400 real files from a real client, it's genuinely likely that a handful will differ in some way the script didn't anticipate: perhaps a different color mode (CMYK instead of RGB), a different bit depth, a corrupted or zero-byte file, an unusual layer structure, or a file that failed to load at all for some other reason. When the script's logic assumes every file will load and behave the same way, and one file doesn't, the operations performed on it (resize, add watermark layer, flatten, export) can silently proceed on whatever partial or unexpected state the file was actually in - producing a blank, corrupted, or wrongly-processed output file - without the script ever recognizing that anything unusual happened, because nothing in the script was checking for it. No error is raised because, from the script's own narrow point of view, every step "succeeded" - it just succeeded on the wrong data. What should have been built in, per this chapter's own point about production-grade batch scripts needing explicit error handling: checks at each step confirming the file actually loaded correctly, that it has the expected properties (dimensions, color mode) before proceeding, and - critically - a log recording which files were processed successfully and which ones triggered an unexpected condition, so a human reviewing the run afterward can immediately see "these three specific files need manual attention" rather than having to discover the problem by inspecting all 400 outputs individually. This logging and validation is exactly the extra work this chapter describes as the real cost of moving from a "happy path" script to a genuinely production-grade one. -------------------------------------------------------------------------- WHY THIS WORKS AS AN ANSWER: It connects the specific symptom (silently wrong output, no error) to the chapter's named cause (a happy-path script with no handling for unanticipated file properties), gives concrete examples of what could have differed about those three files, and names the specific fix (per-step validation plus a success/failure log) rather than a vague "add error handling."