Terminate the workflow at specific time without message box

you have 3 exception mentioned in catches and your trying to terminate the workflow without passing any exception type in “exception” field in the property.
please pass the value and try.

In all the exception blocks I have added the exception object.
Now, I have removed 2 exceptions and kept only 1 exception (with exception object). Still the pop up comes up.

Hi,
Exception field of "Terminate workflow is still kept empty.
Please pass the exception variable there.

Oh, I thought either Exception or Reason property should be set. Well, I set the exception property now. (This terminate workflow is already in catch block.)

exception name you declared in the catch block is “exception” not “New Exception
please pass “exception” in the property …:upside_down:

Tried with that also. No luck .

Can you create a simple workflow for this Terminate Workflow and attach it here so that I will test ?

Here we go. cheers.:+1:
Main.xaml (10.5 KB)

2 Likes

yes, that worked… Thanks.

So you have added a Try catch inside a Try catch block. That’s the way to implement it. Now got it.

The TerminateWorkflow activity in that workflow never executes - Throw before it will abort the execution of current context level.
Sidenote - swallowing exceptions (as in - Catch that does nothing, not even log message) is not recommended and should be done very carefully (I’d say never, but that’s IMHO).

@Chand - are you sure setting it to Private works? Did a quick test, and it doesn’t seem that way. AFAIK setting to Private will only make it not log anything (and it does just that), it doesn’t change the way it behaves. There has to be something else in your workflow that makes it look like it’s working.

Sidenote - TerminateWorkflow activity bypasses Catch clauses in the same workflow and can only be caucght higher in the invoke hierarchy, unlike normal Throw’s.

Most reasonable solution is either what @adrian posted (just throw an error and catch it at the top) or use a flowchart and exit on condition.

See above in my post - it bypasses Catches in current workflows and is the equivalent of telling the robot to “exit this workflow NOW”.

Yep. I believe the Terminate Workflow activity is supposed to throw a popup because it’s basically telling it to stop cause of error. Equivalent to Terminating in Orchestrator.

I would just go with flowchart condition or put all sequences in a Try/Catch with a Throw error when condition is met… or something like that.

Close, but TerminateWorkflow is actually a Microsoft provided activity, so it has nothing to do with Orchestrator.
The popup is a result of an unhandled (as in - not caught) exception, nothing more, nothing less. There are some internal differences on how it works (Terminate sets the workflow to Faulted, while Throw sets to Canceled etc.), but for the most part one does not need to dig that deep since the robot handles that.

2 Likes

Can this be performed in Uipath and pause the robot?

WorkflowInstance instance = runtime.GetWorkflow(instanceId);
instance.Suspend("Paused for some good reason");

// do something here

instance.Resume();
1 Like

I don’t think so, since the exeuction is abstracted through the robot and I’d guess it would need to go through it’s API, which AFAIK doesn’t have suspend exposed.
But since @badita like your post, maybe he’ll tell us :wink:
(note - we’re sidetracking the topic a little bit, though)

Lol…Will create a new topic when needed.

Hi,
Its writing log message.

Main (2).xaml (10.7 KB)

see my code.
Terminal_workflow_Example.xaml (12.8 KB)

Still getting the pop up, as expected:

What would be actually worrying if there would be none - setting the activity to Private should only affect logging, not behaviour. If it would suppress errors, it would mean there’s an undocumented behaviour there.

still same. your code giving message box :upside_down:

yeah :unamused: when I did few days back it was not showing…I dont want any message box and end the workflow.

I have fragmented entire Process in number of modules. If one module does not work, it should terminate the process of that particular module and should go ahead.

In that case, to not change too much, there are 2 choices:

  1. Remove the TerminateWorkflow - since the Catch is the last thing that is executed in that workflow (assuming there’s an error somewhere), it will end as there’s nothing after it.
  2. Move error handling one level higher - wrap the Invoke that calls this workflow with a TryCatch, do a LogMessage in the Catch and nothing more (maybe set a bool to guide further processing, depending on needs). An uncatched Throw acts like a terminate workflow, just let it bubble up the invoke tree until you want to catch it.
2 Likes