Very poor exception handling

[pere]

This is an issue I’ve already complained about.

Exceptions in Studio almost only rely on the “Message”, which is merely a string containing a description of the error, sometimes throwing up everything that comes from the inner library or whatever the activity it’s using, in the form a text string.

When catching exceptions and deciding what to do depending on which exception we got, we need to PARSE the description or “Message” string and looking for certain pieces of text describing the error. I cannot use the words I would use what I think about this because then the salesperson of this company will call me threatening to report it to my boss about “improper behaviour”.

But the truth is that they won’t address any request to fix an activity or any feature request.

We’ve been experiencing a bug for some weeks that’s been a pain in the (censored) to debug because it’s only happening in our production server, but then when we try to reproduce it on our local/development machines, it doesn’t happen anymore. The license in our server is that “unattended robot” one, so when we try to open it there, it says that “with this license you can only use Studio in read mode and for debugging purposes”. But then our project needs some parameters in order to work, and then it won’t let us write in a value for those parameters because the texinputs are greyed out. Oooooh, so smart, UiPath! So you are even blocking write mode for input parameters in the most outer level of our application. We cannot distribute the app with a default parameter because that’s a requirement, so we had to modify it on purpose to provide one, then commit+push it into GIT, then it will allow us to debug in read mode, then after the test revert the modification for the default value, then commit+push again to git. This is a pain in the (censored), and so prone to errors (easy to forget to commit it back to the VCS with a blank value for the default parameter), and very, VERY UNPROFESSIONAL.

Then, once we finally got it to debug, what we found out is that the underlying message (because the activity is making calls to a MS Graph API) of the exception is in another message.

The program was initially getting the message exceptions in English when developing on my local machine.

On the server, the messages are in Spanish, thus invalidating the search; the exception we where looking for remains undetected and then we cannot control what to do accordingly. The error gets propagated and finally it fails in a later part of the sequence.

I have no idea why the error message appears in Spanish on that server. It might be a locale on the virtual machine, but I don’t see a mechanism that’s sending this to the MS Graph server, and that server is the same one as when developing on my machine.

In any case, this could be easily avoided if we could access the usual and very basic exception properties like number error, number code and the like, as in every half decent programming language.

As you see, the code is looking for “The specified (whatever)”… string, to just ignore it and keep going.

Instead, we get the “El nombre del elemento especificado ya existe” error message:

How many languages should we consider when looking for the error message?

If the language used in the error messages suddenly changes to, let’s say Swahiii all of a sudden and we didn’t advance it, we are going to face the same error again.

What if Microsoft simply sligthly changes the error message and our string detection method doesn’t work anymore?

Why can’t we just access the Exception.Code, or Exception.Number or whatever property that’s reliable, doesn’t depend on a locale or human language, and use it for treating exceptions accordingly, as with any other programming language?

Last but not least:

This specific “Create Folder” Sharepoint (from UiPath.MicrosoftOffice365.Activities.Files.CreateFolderConnections") it working, to me, by mere chance. Because some months ago, by merely chance after some package update, you could see during a debug or running session that it’s throwing an error:

“No se puede enviar la solicitud /track/object al servidor de Automation Tracker. Excepción: Bad Request: {“errorCode”:1,“errorMessage”:“The field Key must be a string or array type with a maximum length of ‘128’.”,“traceId”:“00-52dce887cfd6817ef1c5ff49bbb18cdb-ba3415994f48281f-00”}”

Miraculously, even the error, it’s still working. But it’s been running like that for months and it seems nobody at UiPath’s noticed it, or they are not caring at all.