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

Help
,
1

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

RoboticEnterpriseFramework.zip (501.3 KB)

2

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.

Regards.

3 Likes
3

@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

4

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

5

@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
6

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

7

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