a workflow should be able to record all possible errors that may occur. So it is my suggestion that every workflow, which is provided as a component, should contain a parameter named “ErrorRet”. This parameter returns exception and error messages to the calling activity. All error messages must be intercepted internally by the workflow and reported back to the calling activity in the “ErrorRet” parameter. On this way we would go a bit further of standardization of workflow interfaces. This unification makes it easier for users later to integrate workflows into their automation processes.
Why does this need to be an extra parameter? If there is an exception in an invoked workflow it will throw it to the calling activity where it can then be handled. It already contains the exception source, stack trace, message, etc.
I remember well the times when SAP introduced BAPI. One of the main reasons for that was standardized parameters, inter alia the return parameters. Why should we not learn from history, from the experiences others have already made? Yes, you are right, the calling activity can do everything necessary. But the other way around is more convenient for the user. In addition, standardization means simplification, because it allows us to use consolidated approaches.
I’m not denying that.
I’m saying that this functionality is already part of UiPath. All exceptions derive from the common System.Exception class and are already automatically thrown by default when an issue occurs. This is a core part of the .net framework - it’s already standardized. From a user-friendly perspective I think that the built in exception handling is as simple as a parameter would be, if not simpler.
What did you have in mind as a potential use case?
nope, I can do in a invoke code activity in a workflow this:
Dim Key As String = "Hugo" Dim regKey As Microsoft.Win32.RegistryKey regKey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(Key) Dim oError As Object = regKey.GetValue("Bambi")
or I can do that:
Try Dim Key As String = "Hugo" Dim regKey As Microsoft.Win32.RegistryKey regKey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(Key) Dim oError As Object = regKey.GetValue("Bambi") Catch ex As Exception ErrorRet = ex.Message End Try
The first throws an error and the second delivers an error return message. So I have two ways to realize the same inside a workflow. That is not standard. For the first I have can use a try-catch activity in UiPath, for the second I have to request the ErrorRet parameter. That has nothing to do with the dotNET framework or UiPath, these are two different possible ways. In my opinion it is better to decide for one of them as standard. The encapsulation of a workflow is better in the second case, and that is my suggestion.