UiPath-ADPv1 Advanced Debugging Practice Question
You are debugging a UiPath workflow that intermittently throws a BusinessRuleException inside a Try Catch. You want the debugger to pause execution at the exact moment the exception is thrown, before any Catch block handles it, so you can inspect the Locals panel. Which debugging feature should you configure?
⚠ Common exam trap
The trap here is assuming that placing breakpoints inside a Catch block or logging the exception message gives you the same pre-handling visibility as configuring Break on Exceptions for the specific exception type.
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
✓
Enable 'Break on Exceptions' in the Breakpoints panel and set the exception type to BusinessRuleException.
The Break on Exceptions feature in the Breakpoints panel suspends the debugger at the moment an exception is thrown, before the runtime transfers control to a Catch block. Filtering by BusinessRuleException narrows the pause to the exact type you care about, letting you inspect Locals at the original failure site rather than downstream after handling logic has already altered state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a Breakpoint on every activity inside the Catch block to stop after the exception is handled.
Why it's wrong here
Breakpoints inside the Catch block pause only after the exception has already been handled and the stack has unwound. By then local variable values may have changed or been reassigned, defeating the goal of inspecting state at the throw point. This approach also requires manually locating and marking multiple activities.
- ✗
Insert a Log Message activity immediately before the Throw activity to record the exception message.
Why it's wrong here
A Log Message records text to the Output panel but does not pause execution or expose the Locals panel. The workflow continues into the Catch block, so you cannot inspect live variable state at the throw moment. It also requires editing the workflow, which changes the process you are trying to observe, and provides no interactive debugging control.
- ✗
Set the project's 'ExecutionMode' to Debug in the project settings before running the process.
Why it's wrong here
There is no 'ExecutionMode' project setting that controls exception breakpoints in UiPath Studio; execution mode options such as Step Into and Step Over are runtime debugger controls, not a configuration flag. Running in Debug does not automatically pause on thrown exceptions, so the Catch block still executes before you can inspect variables.
- ✓
Enable 'Break on Exceptions' in the Breakpoints panel and set the exception type to BusinessRuleException.
Why this is correct
Break on Exceptions lets the debugger suspend execution the instant a matching exception is thrown, before any Catch block runs. Setting the type to BusinessRuleException means only that exception triggers the pause, so you can open the Locals panel and inspect variable state at the throw point. This is exactly the interruption-before-handling behavior required.
About these practice questions
One of 276 original UiPath-ADPv1 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-ADPv1 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-ADPv1 exam.