Throw Explanation in Reframework when used inside of Invoke Workflow in Process.xaml

Hi Guys,

I am trying to understand how Throw works when it is called from an invoked workflow.
Attached the Workflow sample what i was trying in Process state i invoked a workflow called sequence in that i called throw.
Problem is Throw is stopping the execution
I want the Throw to be catched and move to set transaction status.

Can anybody help me in understanding it…Thanks in Advance (501.3 KB)

As long as you don’t have the Throw surrounded by another Try/Catch in your invoked workflow, then the ReFramework should catch it. If you do have another Try/Catch, you need to use the Rethrow so the ReFramework can catch it.

Looking at your project, you have another Try/Catch surrounding the Throw in Sequence.xaml. I would suggest removing that Try/Catch and letting the Main.xaml catch it, as there is a Try/Catch in the Process state to catch all exceptions. The only time you need to use another Try/Catch inside your Process.xaml or other workflows is to catch specific scenarios and perform different tasks on it. Most of the time, however, you won’t want to use another Try/Catch and let the Main.xaml State Machine do all the error handling.

Hope that helps.

Note: use BusinessRuleException(“message”) for errors in the input that would keep the process from completing and Exception(“message”) for errors that are with the application that could be attempted again.



@ClaytonM Thanks for your inputs.
but when i tried to remove the try catch from invoked workflow… I see that still it is stopping the flow at Throw activity instead of catching and moving to next stepCapture

Are you running it from the Main.xaml? The error handling only works from there.

@ClaytonM i am running in Debug mode… yes running from main.xaml
in normal mode working fine… thanks for help
got info:

  1. Running in debug mode presented a dialog, as described above, which allowed me to manually decide whether to break, ignore, retry, or continue. I see where this might be helpful, because I can control what happens, and most importantly, drop into the code to inspect what happened, like a dynamically created breakpoint.

Indeed, the reason for this pop-up is to try to reproduce during debugging the exact behavior which would happen at runtime. During runtime, if an exception occurs and a handler is defined, the handler would automatically execute and at the end of the handler it will “Continue”, “Ignore” or “Retry” depending on what the handler says/decides/defines. The steps would hence be:

  • activity throws exception
  • handler kicks in
  • execution continues based on what the handler decides
1 Like

Thanks for adding that info in. I didn’t think about Debug mode.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.