UiPath-ADAv1 Debugging and Exception Handling Practice Question
An unattended UiPath robot processes invoices by reading each PDF from a shared network folder, extracting the PO number, and posting it to an internal web application. Extraction works for most files, but a small subset of scanned PDFs fail OCR and throw a business-rule exception that should be logged and skipped without stopping the run. A separate class of failures — the internal web application returning HTTP 500 — must retry a few times before the item is abandoned. The developer wants a single structured design that distinguishes these two failure categories inside the per-invoice loop. Which approach should the developer implement?
⚠ Common exam trap
The trap here is assuming that any catch-all handler or the Global Exception Handler can skip a single bad item and continue the loop, when only a properly typed Catch block inside the loop can do that.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Wrap the per-invoice processing in a Try Catch whose Catch block filters on BusinessRuleException and continues the loop, and place the HTTP retry logic inside the Try block using a Retry Scope activity scoped only to the web-posting sequence.
The scenario needs two distinct exception strategies inside the same loop: deterministic data failures that should be skipped, and transient HTTP failures that should be retried a bounded number of times. Catching BusinessRuleException and continuing the loop handles the unreadable scans, while a Retry Scope scoped to the web-posting sequence absorbs the HTTP 500 without affecting the rest of the item. Combining both in one Try Catch keeps the design structured and predictable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Wrap the per-invoice processing in a Try Catch with a Catch block for System.Exception that logs the error, sleeps for 30 seconds, and then re-invokes the same workflow recursively until extraction succeeds.
Why it's wrong here
Blindly retrying a deterministic OCR failure never succeeds because the scanned PDF will not improve between attempts; the recursion would loop indefinitely or exhaust the stack. A generic System.Exception catch also swallows the distinction between a bad-data business rule and a transient service error, so the HTTP 500 receives the same 30-second delay instead of a bounded, quick retry. The scenario explicitly requires skipping unreadable files, which this design cannot do.
- ✗
Remove all Try Catch activities and rely solely on the Global Exception Handler, configuring it to catch BusinessRuleException and use the Continue activity to resume the For Each loop at the next invoice.
Why it's wrong here
The Global Exception Handler is invoked only when an exception escapes the top-level workflow, so it cannot inspect or resume an inner For Each loop that is still executing. The Continue activity is used inside loops to skip to the next iteration, but it is not valid in the global handler context to recover a specific iteration. This design also provides no retry mechanism for the transient HTTP 500 failures.
- ✓
Wrap the per-invoice processing in a Try Catch whose Catch block filters on BusinessRuleException and continues the loop, and place the HTTP retry logic inside the Try block using a Retry Scope activity scoped only to the web-posting sequence.
Why this is correct
BusinessRuleException is the correct UiPath exception type for deterministic, non-transient data problems such as unreadable scans, and catching it while continuing the loop skips the bad item without halting the run. The HTTP 500 is transient, so isolating the web-posting sequence inside a Retry Scope with a small attempt count lets it recover automatically. This single structure cleanly separates the two failure categories the scenario requires.
- ✗
Wrap the per-invoice processing in a Try Catch whose Catch block catches System.Exception and calls Rethrow, and configure a Global Exception Handler that logs the invoice number and resumes the next item.
Why it's wrong here
Catching System.Exception and rethrowing converts every failure into a fatal fault, so a single unreadable scan stops the whole run instead of being skipped. A Global Exception Handler runs at the outermost layer of the process, not per loop iteration, and cannot resume a For Each loop at the item level. This design also gives no retry path for the transient HTTP 500, so the requirement is unmet.
About these practice questions
Courseiva writes every UiPath-ADAv1 question from scratch — 285 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official UiPath exam blueprint
This UiPath-ADAv1 practice question is part of Courseiva's free UiPath certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the UiPath-ADAv1 exam.