The error still causes the automation to stop.
check the below thread
For Terminal Session
I reproduced an error in a Terminal Session activity with ContinueOnError set to True. The workflow continued as expected with the next activity after Terminal Session. No Try/Catch involved either. Can you elaborate on your observed issue?
I used UiPath.Terminal.Activities v2.0.1.
This has nothing to do with my issue. The problem I am reporting is that when there is an error, the automation fails - it does not respect the Continue On Error setting of the Terminal Session activity.
The Terminal Session activity that failed was one that simply attaches to an existing session (via input variable) and has the “close connection” box checked. The purpose is that when a terminal error is caught, I close the session and then later reopen it.
If the session was already gone for some reason, the subsequent Terminal Session activity that closes it would fail with an error something like there being no session. With Continue on Error set to True, the automation still failed at this point. It wasn’t that an activity inside the Terminal Session failed, it’s that the session (variable) Terminal Session was trying to connect to was Nothing
I reproduced this behaviour and the Terminal Session activity indeed did not continue on error, even though the property is set to True. Error Message: No connection specified.
I still don’t really understand why you would need this scenario though. Can’t you just kill processes related to Terminal activities and restart the application within a framework?
Anyway, expected behaviour of TerminalSession with ContinueOnError=true should be to not throw an exception. Maybe something for @loginerror to add to some internal tracker?
Kill Process is a bad idea. It tries to kill the process for all users on the machine so it could interrupt those jobs. And we are using Direct Connection, which is a process spawned by UiPath Robot, and I’m not sure the consequences of flatly killing it.
Referencing the existing connection and closing it gracefully is the best option, but we need to be able to handle if the terminal connection has crashed etc.
I guess as a workaround I’ll have to put the activity into a Try/Catch and deal with the error that way. Hoping it actually catches the error, as I’ve also read things in the past about errors not being thrown properly by Terminal Session in situations like this.