How to get Display Name of an activity in UiPath 2023.10?

[gopi.janjanam]

Hello Friends,

I am trying build logic, and there was an error in the try block. It got into catch block where I have select system.exception as type and getting error details into exception variable. I have tried all different ways to get “display name” of an activity, but not able to get that. Could some one tell me how to get it ? this will help to log and navigate to exact location when error occured.

Thanks in advance.
Gopi

[mkankatala (Mahesh Kankatala)]

Hi @gopi.janjanam

Can you try this exception.Source.toString

Hope it helps!!

[gopi.janjanam]

It is giving me UiPath.excel.activities instead of display name

[singh_sumit (Sumit Singh Tariyal)]

Hey @gopi.janjanam can you try with
Exception.Stacktrace

cheers

[gopi.janjanam]

Tried that too, it is giving a lot of information but not display name

[Darshan_Sable]

Hey @gopi.janjanam ,

This can be achieve by 2 ways,

1. before each activity set variable “activity name” with display names. Update variable before each activity to store activity name.
   Use try catch and the print the variable “activity name”
   
   
   
   
   

or

2. Instead of try catch you can use global exception handler. Inside handler add log message like below

Hope its helpful to you

[lrtetala (Lakshman Reddy)]

Hi @gopi.janjanam

Can you try to create a separate xaml and invoke it in Try block then you will get that activity name

Regards,

[ashokkarale]

@gopi.janjanam,

Strange but working logic is,

1. Add your try catch logic in a separate workflow
2. Invoke this workflow from, your another workflow
3. Now if you check the Exception.Source, you will get the activity name

[jeevith (Jeevith Hegde, Ph.D.)]

Hi @gopi.janjanam,

Over the years UiPath has changed how you can get hold of the activity name which has failed in a remote workflow.

I would like to add to the answer from @lrtetala and @ashokkarale

Inorder to get the failed activity name (user set display name for the activity)

The important part: You have to have a dedicated workflow WITHOUT any TRY-Catch. So in short, this workflow just fails without handling any exceptions. Lets call this ProcessLogic_SomeWorkflowName

Now you create a new workflow as show in the screeshot of @lrtetala and invoke your ProcessLogic_SomeWorkflowName. Lets call this workflow as Wrapper_SomeWorkflowName. This workflows main function is to catch the exception and send it forward to your Process.xaml file
Another important thing is to ensure that the invoked workflow should not be surounded with a dedicated sequence. Below image is the right way to use this approach.

So you see what we did, we now have access to the exception object inProcessLogic_SomeWorkflowName.
This will work with many invokes as well in the Wrapper.

Now in the Catch block you have a lot of options with the exception object. For example, there is a dictionary named “Data” to which you can add additional keys in your catch block. We add an additional key in our Wrappers and call it WrapperName like so.

There is also the FaultedDetails key which gives you more metadata WorkflowException.Data("FaultedDetails")

Finally, you can send the exception object out to Process.xaml to process it further or let it bubble up to Process Transaction state in Reframework.

My advice to you would be to explore the exception object more (in the Wrapper) and add required keys in it and let the Process.xaml handle these further. We handle or check for any exception after each invoke of the Wrapper in Process.xaml like so.
Then we append the requrired error messages to a log format and log it.

That said, Is this the recommended way to handle exceptions?

According to Microsoft documentation this is NOT a good way to handle exceptions. Exceptions need to be handled at the source of failure first ( Best practices for exceptions - .NET | Microsoft Learn) and bubbling up of exceptions should be avoided as much as possible.

I am not aware of any other way in UiPath to get the information we are looking for without bubbling exceptions.

About global handler
For what it is worth, stay away from using global handler to perform any such checks. I disable the global handler for all projects. If you handled your exceptions correctly you will anyway not end up in the global handler. It is nice to have but not a must have.