No exception variable available anymore in a Try..Catch

[pere]

I’m suffering from the same bug/usability issue as this user:

Unable to find the exception variable in Try Catch activity - Help / Studio - UiPath Community Forum

Since they changed the user interface, for nothing else than bothering the user, introducing new bugs, removing functionality and not adding anything new, the ability to choose the name of the exception variable and, more important, have an actual idea of where it is gone, has disappeared.

I wonder what kind of UI architect makes this kind of decision.

For most of the times I’ve already found out that the exception variable is “exception”.

Yet when you want to catch different kinds of exception in a try..catch block, when other then the general System.Exception, I have no way to find what this variable is:

With the System.Exception I can do a .ToString of the “exception” variable:

For the System.AggregateException, it doesn’t recognize the “exception” variable. It doesn’t complain in the visible Log Message “card”, yet inside the “Message” detail there’s an exclamation:

I even asked the integrated AI to generate this for me, to see if maybe it was able to find out what the name of the variable was. Guess what? It wrote “exception”, which, obviously, didn’t work.

End the end, we cannot see what the exception is complaining about; we had to remove the variable to string there in order to display/log an error.

This regression is so lame, as well as so many others with this unnecessary theme update, while many of the bugs and usability issues we reported as long as almost three years ago remains unaddressed.

[sonaliaggarwal47 (Sonali Aggarwal)]

Hi @pere

1 question..

Is there any reason you want to refer to aggregate exception separately?

Under main system exception, it can still be referred.

Please note: If you want to use aggregate exception, you will have to use a loop to print the exception message of each exception under same as it is an aggregate of multiple inner exceptions.

[pere]

Hi @sonaliaggarwal47,

I don’t know if I’m getting it properly, but of course the control flow is like that for a reason. If you are suggesting that we get rid of a basic functionality like catching exceptions from higher specificity to less specificity that we have been making use of for years, with UiPath or any programming language, because of a poorly designed UI change and/or an introduced big, it doesn’t make sense. And of course we already have ideas to workaround bugs, but that’s not the purpose of this thread.

If the interface is allowing us to implement diferent kind of catches for different kinds of exceptions, and it was working until now, what they have is to fix the bug or to remove the functionality. If Studio is going to allow catching only a general exception and we have to inspect it and do our coding for identifying the specific kind of exception and act accordingly, then don’t allow to set up more than one catch; that’s it. Any other kind of suggestion is not acceptable.

[Jeroen_van_Loon]

This is what happens when a product owner won’t accept that a product on some level is finished. Out of their own job preservation instinct, as long as there is stuff on the backlog they get to eat. Filtering bad ideas is then diminished.
Meanwhile, UiPath innovates on their platform in other areas, mostly on the self fulfilling prophecy AI/Agentic. Extracting competent developers to their focus area, leaving the less skilled to f* up the RPA part with useless rebuild. “Change is good, any” is a very common effect.

All assumptions, I know, but not an unlikely factor in issues like these.

[J0ska]

I am not sure if I got your point.

I tried to simulate the scenario:
in TRY block I throw the AggregateException
it is catched in CATCH block
and the generic “exception” variable is processed without error

there is indeed the confusing error message in expression editor, but it doesn’t harm anything

Cheers

[postwick (Paul Ostwick)]

I have seen this happen with various products over the years, and it is indeed happening with UiPath.

[pere]

It doesn’t harm anything?

If it shows up as an error, what do you think users should do? Get rid of it or leave it there?

If it’s not an error, then remove the error message.

If “exception” is the hardcoded name of the variable we have to use, then explicitly state it.

Those are too many assumption for us to make.

[pere]

Is finished? I wish so.

We have reported plenty bugs, made dozens of simple usability requests, like being able to sort the variables list alphabetically and keep the sorting, blank screens when changing from one tab to another, being able to see the attached pictures in the customer support section instead of corrupted icons, or to keep sessions across subsequent Powershell calls, like it used to happen in “legacy” projects.

None of them have been addressed since I started working with the 3 years ago. And licenses are not cheap.

[J0ska]

You are right. But sometimes I am happy if all works regardless missleading error messages

And documentation .. it this has never been a strong point of UiPath

Cheers

[Raluca_Laic]

Hi @pere ,

I’m really sorry that you’re encountering this issue.

Currently, there are two problems affecting the exception variable in the Catch block:

• The exception variable name can no longer be viewed or edited in the Catch block. Speaking to the team, the name of the exception in the catch block is exception.
• The exception variable is not always available through IntelliSense. From what I’ve observed, saving and reopening the workflow usually makes it appear again.

We’re taking this feedback seriously, and the engineering team is working on addressing these issues.

I’d also like to learn more about the additional problems you mentioned, such as the variables list and the blank screens. I’ll reach out to you to gather more details about what you’re experiencing.

Many thanks,
Raluca

[dbiswas (DEBABRATA BISWAS)]

Hi @Raluca_Laic, naming of exception variables helps us to identify the correct exception in case of a nested try catch (as example below). Is it possible for the product development team to bring back naming of exception variable?

try{
//code1
}catch(Exception e1){
try{
//code2
}catch(Exception e2){
//at this point we can identify e1 and e2 individually for better reporting and handling of errors
}
}