Not the automation that crashes.<\/p>\n
The automation that fails and reports success.<\/strong><\/p>\n An error is caught, the automation exits cleanly, the orchestrator records a completed run. Nobody is alerted. The data did not arrive.<\/p>\n Somebody discovers it three weeks later<\/strong> when a report is short, and by then nobody can reconstruct what was missed.<\/p>\n Everything in this article is about preventing that.<\/strong><\/p>\n One try-catch around the whole thing tells you something failed.<\/strong><\/p>\n One per stage tells you which.<\/strong><\/p>\n A file-handling automation has natural stages: download, extract, find the file, validate, upload. Each gets its own protected block.<\/strong><\/p>\n Then the log says “extraction failed”<\/strong> rather than “an error occurred”, and whoever picks it up knows where to look before opening anything.<\/p>\n FIGURE 1: STAGES, EACH PROTECTED<\/p>\n Download<\/p>\n Extract<\/p>\n Validate<\/p>\n Upload<\/p>\n For an unattended job, the log is all anyone will have.<\/strong><\/p>\n Log both:<\/strong><\/p>\n The error message.<\/strong> What went wrong, in words.<\/p>\n The stack trace.<\/strong> Where in the automation it happened.<\/p>\n Without the trace<\/strong>, a generic message like “object reference not set” tells you nothing useful. With it, you know the step.<\/p>\n And log the successful runs too.<\/strong> A gap in a success log is visible. Nothing at all is not.<\/p>\n The single most important line in this article.<\/strong><\/p>\n When you catch an error, log it \u2014 and then re-throw it.<\/strong><\/p>\n Why:<\/strong> catching an error and continuing means the automation exits normally. The orchestrator marks the job successful. No alert fires.<\/p>\n You have converted a visible failure into an invisible one.<\/strong><\/p>\n A failed job is a signal.<\/strong> It appears in the orchestrator, it triggers alerts, somebody sees it.<\/p>\n A false success is silence<\/strong>, and silence looks exactly like everything working.<\/p>\n The only exception:<\/strong> when you have deliberately decided that this particular failure should not stop the run \u2014 one bad record out of five hundred, for instance. Even then, log it and report it in a summary.<\/strong> Continuing is not the same as ignoring.<\/p>\n FIGURE 2: WHAT HAPPENS AFTER A CATCH<\/p>\n Re-thrown<\/p>\n Swallowed<\/p>\n A log file is not an alert.<\/strong><\/p>\n Four requirements:<\/strong><\/p>\n A named person.<\/strong> Not a shared inbox nobody reads.<\/p>\n Enough context to act.<\/strong> Which automation, which stage, what error, when.<\/p>\n Reaching them in time.<\/strong> For an overnight job, in the morning at the latest.<\/p>\n Including the case where the job did not run.<\/strong> A scheduled run that never started produces no error at all. Monitor for the absence.<\/strong><\/p>\n That last one is the most commonly missed<\/strong>, and it is the failure that lasts longest \u2014 because there is nothing to notice.<\/p>\n Do not assume a step worked because it did not error.<\/strong><\/p>\n After downloading:<\/strong> does the file exist? Does it have content? Is it the right type<\/strong> \u2014 a download can return an HTML error page with the extension you expected.<\/p>\n After extracting:<\/strong> were any files produced?<\/p>\n After finding:<\/strong> was a match found, and does it exist on disk?<\/p>\n After uploading:<\/strong> what did the response say? A success status with a body reading “0 rows processed” is a failure wearing a success badge.<\/p>\n Checking is cheap. Discovering it downstream is not.<\/strong><\/p>\n FIGURE 3: WHAT TO CHECK AT EACH STAGE<\/p>\n After download<\/p>\n After extract<\/p>\n After find<\/p>\n After upload<\/p>\n Some failures are temporary.<\/strong> A brief network problem, a service restarting, a rate limit.<\/p>\n Retry those.<\/strong> With a limit, and with a pause between attempts.<\/p>\n Do not retry everything.<\/strong> A file that does not exist will not exist on the third attempt either \u2014 retrying just delays the alert.<\/p>\n A useful split:<\/strong> retry network and availability problems. Fail immediately on validation and logic problems.<\/p>\n When processing many items, one fails. What now?<\/strong><\/p>\n Continue<\/strong> when items are independent. Log the failure, carry on, report everything at the end.<\/p>\n Stop<\/strong> when items depend on each other, or when a partial result would leave things inconsistent.<\/p>\n Decide deliberately per automation<\/strong>, rather than accepting whatever the default is.<\/p>\n And whichever you choose, you must know where it got to.<\/strong> A run that failed halfway with no record of what completed is the worst outcome \u2014 you cannot safely re-run and you cannot safely continue.<\/p>\n Every batch automation should report at the end:<\/strong><\/p>\n Sent to a person.<\/strong><\/p>\n Without this, a run that half-worked looks identical to one that fully worked.<\/strong><\/p>\n The step everyone skips.<\/strong><\/p>\n Deliberately break things and confirm the handling works:<\/strong><\/p>\n Then check:<\/strong> did the job fail? Did the alert arrive? Does the log say which stage?<\/p>\n An error handler nobody has tested is not error handling.<\/strong> It is code that has never run.<\/p>\n Try-catch per stage<\/strong>, so the log says which one failed.<\/p>\n Log the message and the stack trace<\/strong> \u2014 for an unattended job, that is all anyone will have.<\/p>\n Re-throw so the job is marked failed.<\/strong> A swallowed error becomes a false success, and a false success is silence.<\/p>\n Alert a named person, including when the job did not run at all.<\/strong><\/p>\n And test the failure path deliberately. The handler that has never run is the one that will not work when it matters.<\/p>\n Automations that might be failing without anyone knowing?<\/p>\n Get in touch. We build error handling that fails loudly \u2014 and we test it by breaking things deliberately.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The failure that costs most Not the automation that crashes. The automation that fails and reports success. An error is caught, the automation exits cleanly, the orchestrator records a completed run. Nobody is alerted. The data did not arrive. Somebody discovers it three weeks later when a report is short, and by then nobody can […]<\/p>\n","protected":false},"author":3,"featured_media":9374,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9373","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nTry-catch per stage, not per automation<\/h2>\n
\n
\n
\n
\n
Log the message and the stack trace<\/h2>\n
Re-throw so the job fails<\/h2>\n
\n
\n
Alerts must reach a person<\/h2>\n
Validate at each stage<\/h2>\n
\n
\n
\n
\n
Retries<\/h2>\n
Deciding continue-or-stop<\/h2>\n
The run summary<\/h2>\n
\n
Testing the failure path<\/h2>\n
\n
The short version<\/h2>\n