Hi, I am working with Level 3 Assignment 1 with Reframework. While creating the ACME System1 Login Project, I am facing an issue.
According to the attached walk through, it hints on creating a Throw activity in order to throw an Exception and then it should directly end the process after throwing it:
In my case, when running the workflow with wrong credentials to test, the Workflow is not stopped after the Throw activity, but instead is stuck and does not completely ends. How come this happens, and am I missing something with the throw activity?
Unfortunately I could only find one relateable topic in the forum with the same problem, but this did not help solve my issue - and also got stuck in the Throw activity before being able to move on to the referred Assign activity:
As I read through your discussion and a tiny bit discouraged, I am now pounding my head to make some sense out of this and getting desperate for some suggestions…
As seen on my question above, the guide suggests using a throw activity and that should’ve been correctly instantiate as seen above with custom exception method in the Throw activity. Unfortunately, it is stuck, unable to end after entering the Throw activity does any of you guys have the experience with this and how I can troubleshoot this specific Throw activity issue?..
Reason it says “Executing” and “Closed” and so on, I believe, is because you have Tracing or Debugging on. So, I don’t think those logs are that helpful really.
First thing you would want to do is run the individual Login workflow by itself, and it should not be surrounded by a Try/Catch. The reason why it should not be surrounded is because you want the Error/Handling to happen globally. (but there are exceptions to this). When you run the individual workflow, you would get the error message when it hits the Throw (assuming the credentials are invalid). This will tell you that it is working as intended.
Then, your main workflow (such as the REFramework) would have an invoke to all your tasks, and that invoke would be surrounded by the Try/Catch.
Therefore, when you run your main, you will get errors that occur. This can always cause some confusion, like “what tha…? … it didn’t work but there were no errors?” A Rethrow can be used in the Catch (but I recommend only temporarily for troubleshooting) to see what actually happened when an error occurred. Additionally, you should have at some point a Log Message to show what the error was that happened and any retry attempt identifiers; this is usually in the Finally part of the Try/Catch and will be in the SetTransactionStatus workflow if you use the REFramework.
Does this help? Sorry if I confused you.
If it gets stuck infinitely, try adding a Write Line after the Throw to identify if it’s just a bug. At one time, there was a glitch where it ended the process but “didn’t really end it”. If it’s that glitch, try updating your Studio or .NET Framework
Thank you for your time and suggestions yesterday, which actually helped clear up some doubts I had in mind, but unfortunately not resolving the issues.
I think I’ve isolated pretty much by using your suggestions.
I have ran the login project on it’s own and isolating any issues with the REFramework. I’ve also made the length of creating a new empty project with just an If/else statement (activity) in it, to test the throw activity and that the project file itself was not the culprit, the weird thing is that the same thing happened on a new clean project also… It can’t be Expression mispells
Yes, it gets stuck infinitely, I just booted my computer again after sleep mode, and to realize the test project was still stuck running on the Throw activity… haha.
I will try the trick to update the .NET Framework, as I know the feature can be affected by our domain joined laptop devices, since feature updates are controlled by our WSUS-servers (enterprise environment). I will also at the same time test with a non-domain joined machine that has been reinstalled to factory, just to see how it goes.
I checked up on this issue and there seems to be a problem with the Community Studio version after troubleshooting this. I can conclude with the following:
Same problem happens to a newly factory resat device with updated .NET Framework & Community Studio 19.8.0 downloaded and installed from the Orchestrator resource page. However the problem got resolved when I uninstalled and replaced the Community Studio version 19.8.0 with the Studio Enterprise 19.4.4.
Throw activity now works as intended in Studio Enterprise 19.4.4
I also tried to downgrade the UiPath.System.Activities to match 19.4.1 in Community Studio 19.8.0, but same bug appeared.
So our question now is:
Is there a difference in the statement of Throw activity between those two Studio versions… Or did anything change in between?..
Both tests were made in a vb.net template. And since I don’t know if the syntax is written the same in C#, I’ve not given it a try yet…
Is this something you guys are aware of or maybe are able to replicate with a Community version of 19.8.0?..
ashokkarale
anjani_priya
Dheerendra_vishwakarma
Parvathy
Aakash_Singh_Rawat
Luis_Fernando
bjorn2390
neco
pere
Shiva_Nikhil