作者简介:博主是一位.Net开发者,同时也是RPA和低代码平台的践行者。
个人主页:会敲键盘的肘子
系列专栏:UiPath
专栏简介:UiPath在传统的RPA(Robotic process automation)的基础上,增加了See(AI通过计算机视觉阅读用户的计算机屏幕)和Think(通过机器学习来发现平台能够为用户构建什么自动化流程)从而不断帮助用户自动化构建流程,而不仅仅是用户自主发现,自主构建。并且在构建的过程当中,做到了Low-code甚至是No-code的程度,让每一位员工都可以自主使用。
座右铭:总有一天你所坚持的会反过来拥抱你。
写在前面:
本文介绍了做好Automation Process准备工作中最重要的一部分:
如何预测、检测和处理流程中的异常
。我们将首先介绍UiPath中遇到的常见异常。然后我们将介绍特定的异常处理活动
TryCatch、Throw、Rethrow、Retry Scope和Global Exception Handler
。我们还将了解UI自动化活动共享的一个非常有价值的属性ContinueOnError
。
本文关键字:RPA、UiPath、Low-code、No-code、异常处理、.Net
RPA(Robotic process automation) 代表机器人过程自动化。
它是一种软件程序,可在与计算机应用程序交互时模仿人类行为并实现重复的、基于规则的流程的自动化。
UiPath 是一种机器人流程自动化工具,用于自动化枯燥和重复的任务。它由罗马尼亚企业家 Daniel Dines 和 Marius Trica 于 2005 年创立。它还消除了自动化无聊任务的人工干预,并为所有活动提供了拖放功能,它是最简单的 RPA 工具。
UiPath在传统的RPA的基础上,增加了See(AI通过计算机视觉阅读用户的计算机屏幕)和Think(通过机器学习来发现平台能够为用户构建什么自动化流程)从而不断帮助用户自动化构建流程,而不仅仅是用户自主发现,自主构建。并且在构建的过程当中,做到了Low-code甚至是No-code的程度,让每一位员工都可以自主使用。
因为创建自动化项目的最终目标是将其投入生产。
当我们的流程在生产中运行时,可以合理地预期,我们开发流程的理想条件可能会随着时间的推移而改变。资源可能变得不可访问,选择器可能更改,输入数据可能以意外的格式提供,等等。
当机器人遇到不准备处理的情况时,它会抛出异常。
异常处理意味着提供识别这些事件并从中恢复的指令。而未处理的异常将终止执行。
UiPath Studio Community 2022.4.3
Windows 10
.Net
通过本文,您可以学会:
识别并区分不同类型的异常。
描述常见的异常处理技术,并解释何时使用它们。
在自动化项目中使用TryCatch、Throw和Rethrow
活动。
在自动化项目中使用Retry Scope
活动。
描述ContinueOnError
属性。
在有人参与和无人参与的情况下使用全局异常处理
程序。
在了解最常见的异常之前,让我们快速区分错误(errors)和异常(exceptions):
Errors是特定程序通常无法处理的事件。根据导致错误的原因,有不同类型的错误,例如:
Syntax errors,编译器/解释器无法将编写的代码解析为有意义的计算机指令。
User errors,其中软件确定用户的输入由于某些原因不可接受。
Programming errors,其中程序不包含语法错误,但不产生预期结果。这些类型的错误通常被称为bug。
Exceptions是程序识别(捕获)、分类和处理的事件。更具体地说,有一个由开发人员配置的例程,当捕获到异常时会被激活。有时,处理机制可以简单地停止执行。一些Exceptions与所使用的系统有关,而其他Exceptions与业务流程的逻辑有关。
让我们详细了解不同类型的异常。
以下是在使用UiPath开发的项目中可能遇到的最常见的异常列表。
一般来说,下面提到的所有这些异常类型都是从System派生的。异常,因此例如在TryCatch中使用此泛型类型将捕获所有类型的错误。
业务异常主要是指Automation Process中使用的信息。从商业角度来看,它可能不完整或不正确。
当发生业务异常时,机器人会停止流程,并且需要人工干预来处理抛出的异常。
业务异常的一些例子是:自动化项目所依赖的某些数据不完整、缺失、超出了设定的界限(比如试图从ATM中提取超过每日限额的数据),或者没有通过其他数据验证标准
。
业务规则异常不会自动生成为系统异常。它们必须由开发人员使用Throw Activity
定义,并在TryCatch
中处理。
本章节结束,您可以学会:
描述常见的异常处理技术,并解释何时使用它们。
在自动化项目中使用TryCatch、Throw和Rethrow
活动。
TryCatch
活动捕获序列或活动中指定的异常类型,并显示错误通知或将其取消并继续执行。
作为一种机制,TryCatch运行Try块中的活动,如果发生错误,则执行Catches块中的行为。Finally块仅在未引发异常或在Catches块中捕获并处理异常时执行(不重新引发)。
有可能引发错误的活动。
发生异常时要执行的活动或活动集。
注意:您可以将多个异常和相应的活动添加到此块。
每当发生异常时,如果catch块无法处理它捕获的特定异常,您可以重新抛出异常。重新抛出会导致最初抛出的异常被重新抛出,以在更高级别上处理该异常。
执行Try和Catches块后要执行的活动或活动集。只有当没有抛出异常或发生错误并在Catches块中捕获时(不重新抛出),才会执行此部分。
我们今天要处理的项目从excel文件读取输入数据,调用登录到UI演示应用程序的工作流,在提取的DataTable的行中循环,在UI演示字段中键入值,然后单击接受按钮。
让我们看看输入的Excel文件。
由于我们使用的是Read Range
活动,如果Excel文件在执行开始时打开,则流程会抛出异常。
我们将使用这个案例演示如何使用Try-Catch处理异常。
让我们运行这个项目,看看会发生什么。
这是一个错误。在错误消息中,我们可以看到:
引发异常的活动的名称-尝试读取输入数据
错误消息–进程无法访问该文件,因为另一个进程正在使用该文件
异常类型是System.IO.IOException
。
添加Try Catch
的最简单方法是右键单击某个活动或序列,然后选择Surround with Try Cath
操作。我们还有一个键盘快捷键:ctrl+T
。
另一个选项是从Activities(活动)面板添加它。
Try Catch
活动捕获序列或活动中的一个或多个指定异常类型,并提供执行恢复和继续执行或抛出异常的选项。
该活动包含三个模块:
Try块保存可能引发异常的活动或序列。
Catches块允许我们指定一个或多个异常类型,并为每个catch提供特定的步骤。
Finally块包含一个活动,只有在未发生错误或已捕获错误时才应执行该活动。
最常见的异常类型是System.exception。它包括所有其他异常类型,因此处理步骤适用于任何抛出的异常。
现在您可能会想:“好吧,如果我们正在监视多个异常类型,其中一个包括另一个,比如System.exception和System.ArgumentException,会怎么样?”。
在这种情况下,如果系统。ArgumentException在运行时被捕获,那么在Catches块中执行的案例是最具体的案例,属于System.Argument异常。
对于我们的示例,因为我们知道抛出了什么类型的异常,所以我们将选择“SystemIO.IOException”,这是我们前面看到的抛出的异常。
在这里,在IO异常的捕获情况下,如果捕获到这种类型的异常,我们可以添加希望机器人执行的活动。
请注意,异常对象包含有关捕获的异常的信息。我们可以在这个块中引用它。
让我们在catch块中添加一个LogMessage
活动,并将其级别设置为warn
。
我们要显示的消息是异常错误消息,后面是异常源。这两条信息都存储为异常对象的属性。“异常点源”处的“异常点消息”。
接下来,我们将添加恢复步骤。让我们包括一个KillProcess
活动并添加我们的流程的扩展。请记住,此活动将关闭所有打开的Excel文件。
在Finally块中,我们将添加一个If
语句,其中的条件是:如果我们的数据表什么都不是,那么读取输入数据活动。
现在,让我们从Try块复制Read Input Data
活动,并将其粘贴到If语句中。
让我们在打开Excel的情况下再次运行项目。
我们的项目已成功处理错误!
数据被输入到UiDemo应用程序中,有关捕获的异常的信息被记录在输出
面板中。
接下来,让我们关注Throw
活动。
当我们想要抛出异常时,即使它不是由活动生成的,也会使用此活动。
知道有两个关键的异常类别是非常有用的:应用程序异常,如我们迄今为止看到的异常,以及业务规则异常,这些异常不会给机器人造成问题,但会破坏流程的业务规则。例如,试图从ATM取款超过每日限额会产生业务规则异常。
在我们的示例中,假设我们有一个业务规则,规定在UiDemo应用程序的任何字段中都不能添加大于100的值
。
如果需要输入大于100的值,流程将抛出业务规则异常,执行将停止。否则,它将在UiDemo应用程序中键入值。
所以,让我们添加一个If
活动,正确命名并配置它。
让我们添加条件字段Convert.ToInt32(row(1).ToString)>100
。
在Then
分支中,我们将添加Throw
活动。
对于Exception
属性,我们将实例化一个新的Business Rule Exception
对象,并显示消息值超出范围,值大于100
。
接下来,让我们将UIDemo应用程序中处理数据输入的序列移到Else部分。
我们保存并运行工作流,看看现在会发生什么。
我们可以注意到,机器人只会输入第一行值,然后在到达第二行时抛出错误
。
请注意,错误消息与应用程序异常显示的消息类似。我们可以看到我们在Error属性中提供的消息,异常类型为UiPath.Core.BusinessRuleException
。
事实上,通过在工作流中使用Try-Catch
活动来处理意外的应用程序异常。或者通过使用条件块验证数据,并针对业务异常抛出活动。
接下来,我们在catch块内使用Rethrow活动,并将再次抛出最初捕获的异常。
这对于我们希望捕获异常以进行日志记录,但无法恢复的情况非常有用。
在这种情况下,我们可以简单地记录消息,重新抛出错误,并在父工作流中捕获此错误。
本章节结束,您可以学会:
Retry Scope
活动。只要不满足条件或引发错误,Retry Scope
活动就会重试包含的活动。
此活动用于捕获和处理错误,这就是它类似于TryCatch的原因。不同的是,该活动只是重试执行,而不是提供更复杂的处理机制。
该活动有两个主要部分行动和条件。
它可以在没有终止条件的情况下使用,在这种情况下,它将重试活动,直到没有异常发生或超过所提供的尝试次数。
它还有两个附加属性NumberOfRetries
和RetryInterval
。
下图显示了UiPath Studio中使用的重试范围活动及其属性。
首先是行动部分。
这一部分只是一个序列,我们可以在其中放入任意多的活动。这些活动将至少进行一次。
行动部分中的活动会发生什么?
如果出现错误,将重试这些活动。或者,如果条件设置了,但不是真的,则重试它们。基本上,我们可以在Action部分中有一到无穷多个活动。在我们的例子中,这只是一个活动,它正在尝试单击“另存为”。
下一节是条件部分
它只能有零个或一个活动。它不能有更多的活动。此活动输出需要是布尔值,如true或false。因此,在结束时,在运行所有操作后,如果检查了条件并为False,则将再次重试。
如果选中的条件为True,则不会出现重试。它将按顺序移动到下一个活动。
其中使用的基本或常见活动包括:元素存在、文件存在、检查真和检查假。但任何变成布尔值的活动都可以。
首先是NumberOfRetries,它是可以重试操作部分中的活动的重试次数。
它指定了如果连续抛出异常或不满足条件,所包含的活动应执行的最大次数。
例如,如果将重试次数设置为两次,则操作序列可以运行的总次数或最大次数为两次。
我们有重试间隔,这是一个持续时间。RetryInterval指定每次重试之间的时间间隔。
这些以小时、分钟、秒的格式书写。我们可以设置任何值,默认值为5秒。
如果操作部分有错误,它甚至不会检查条件,它会重试包含的活动。如果操作部分没有错误,那么它将检查条件。
如果条件为真,也就是说,如果弹出窗口像我们的情况一样存在,它将不会重试。它将继续到下一个活动。
但如果操作成功,则没有错误,我们将检查元素是否存在。如果元素还不存在,这意味着没有弹出窗口,我们将等待五秒钟,然后再次尝试操作序列并重新检查条件。
Retry Scope
活动用于捕获和处理错误,这使其类似于Try Catch
活动。
只要不满足条件或抛出错误,重试作用域就会重试包含的活动。
例如,考虑在加载按钮之前单击按钮并检查结果弹出窗口是否出现的情况。或者是另一种下载文件并在下载完成之前尝试读取的情况。在所有这些情况下,重试作用域都会像do-while循环一样运行操作并检查条件。
我们将从这个演示的预构建项目ACME下载月度报告开始。
它的目的是从ACME System One页面下载月度报告,机器人在其中填写输入,如Vendor TaxID、月份和年份。
点击下载报告按钮并将其保存到驱动器上的路径。
这被假定在一个循环中,循环我们每年需要的月份。
首先,我们假设我们已经登录了ACME,并且我们在下载月度报告页面上。最后,我们应该有一个特定输入月份、年份和税务供应商ID的下载报告。让我们先看看使用的参数。这些是我们将在工作流中使用的参数及其默认值。
我们已经使用附加浏览器活动附加了ACME下载月度报告浏览器。
我们已经为供应商税务ID使用了“键入”活动,我们已经选择了年份和月份。为了执行这些活动,我们使用了单击活动。
接下来,我们为下载报告按钮添加了单击活动。
下载报告将在Edge中有一个小弹出窗口,其中包含“另存为”。
因此,我们为“另存为”添加了另一个单击活动。
最后,我们添加了一个“键入”活动来键入文件名,以提供项目文件夹的路径,并添加了一次单击活动来保存它。
我们看到Robot填写了详细信息、供应商税务ID、年份和月份,然后单击下载报告。
然后应该会有一个保存为的弹出窗口,但它来得不够快。
基本上,工作流无法单击另存为,因为另存为的弹出窗口很慢且延迟。
因此,我们有一个运行时执行错误,说明它无法单击“另存为”,并且找不到元素,因为它不够快。
现在让我们单击OK,然后放下输出面板。
现在,让我们再打开Edge一次,我们看到这个弹出窗口在这里,但它很慢,很延迟。
我们想让机器人点击另存为,但它做不到。
为了克服这种情况,我们可以使用Retry Scope
来重试包含的活动。因此,我们将使用Retry Scope
活动继续重试“另存为”活动。
让我们在活动面板中搜索Retry Scope
活动,并将其放在另存为活动的正上方。
对于我们的动作部分,我们将如何配置它?
我们将把点击保存为活动放到操作中。
然后我们将使用Element Exists
活动设置条件。
条件活动返回True或False,此时,我们想检查是否出现另存为弹出窗口?如果是,那么我们不需要再次单击“另存为”。我们可以继续键入文件名。如果没有,我们需要再次尝试单击以弹出弹出窗口。
让我们单击“另存为”,并让弹出窗口显示。
让我们回到Studio并在屏幕上指示元素“另存为”窗口。
要微调选择器,我们需要重新指示它。
让我们打开UI Explorer
来指示Save As元素的选择器。让我们单击“保存”、“验证”,然后单击“确定”。
很好,我们找到了我们想要的选择器。
让我们遵循重命名活动的最佳做法,将“元素存在”活动重命名为“元素存在另存为弹出窗口”。
现在,我们需要做的最后一件事是,单击重试范围来探索这里的属性。
重试范围活动有两个关键属性:NumberOfRetries和RetryInterval。
让我们看看。
首先是NumberOfRetries,它是可以重试操作部分中的活动的重试次数。
它指定了如果连续抛出异常或不满足条件,所包含的活动应执行的最大次数。
例如,如果将重试次数设置为两次,则操作序列可以运行的总次数或最大次数为两次。
我们可以进去五次。如果在重试次数字段中未设置任何值,则默认值为3。
然后我们有重试间隔,这是一个持续时间。RetryInterval指定每次重试之间的时间间隔。
让我们重置浏览器并点击跑步。它工作得很好,报告已成功下载!
让我们检查输出面板,我们看到只花了20秒就完成了这项工作。其中五秒钟我们都在等待,如果我们回到浏览器,文件就会被下载。我们已经准备好继续前进,让它再次循环。
ContinueOnError是一个属性,它指定即使活动抛出错误,活动的执行是否应该继续。
此字段仅支持布尔值(True、False)。默认值为False,因此,如果字段为空并引发错误,则项目的执行将停止。如果该值设置为True,则无论出现任何错误,项目都会继续执行。
如果某个活动的ContinueOnError设置为True,而该活动具有一个范围,例如(经典的“附加窗口”或“附加浏览器”,现代的“使用应用程序浏览器”),则相应范围“活动”的DO容器内的所有活动引发的错误也将被忽略。
不建议在所有情况下都将此属性设置为True。但也有一些是合理的,比如:
使用数据抓取时-这样当“下一步”按钮的选择器不再找到时,活动不会在最后一页上抛出错误。
当我们对捕获错误不感兴趣,而只是对活动的执行感兴趣时。
全局异常处理程序是一种工作流,用于在遇到意外异常时确定流程的行为。这就是为什么每个自动化项目只能设置一个全局异常处理程序的原因。
在其默认配置中,全局处理程序在运行时捕获流程中任何活动引发的异常,并执行标准响应-忽略、重试、中止或继续,如设计时预定义的。对于有人参与的场景,可以将其配置为允许用户选择操作。
可以通过添加具有此类型的新工作流文件来创建全局异常处理程序。也可以通过在“项目”面板中将现有工作流设置为“全局异常处理程序”来创建该工作流。
它是如何工作的?
全局异常处理程序有2个预定义参数,不应删除:
errorInfo with the In direction-包含有关引发的错误和失败的工作流的信息。
result with the Out direction-用于确定进程遇到错误时的下一个行为。
全局异常处理程序包含以下预定义的活动。如果需要,我们还可以在Handler中添加其他活动。
开发人员可以选择在执行过程中遇到错误时要采取的操作:
Continue-重新引发异常。
Ignore-忽略异常,并从下一个活动继续执行。
Retry-重试引发异常的活动。
Abort-运行当前处理程序后,执行停止。
全局异常处理程序不适用于库项目,仅适用于进程。
只有未捕获的异常才会到达异常处理程序。如果TryCatch活动内发生异常,并且在Catches块内成功捕获并处理了该异常(且未重新引发),则该异常将不会到达全局异常处理程序。
只有一个全局异常处理程序 可以根据自动化项目设置。
让我们创建一个新的全局处理程序。我们可以通过两种方式将其添加到我们的项目中:
我们可以右键单击现有的XAML文件并将其设置为项目的全局处理程序或者通过单击“新建”并选择“全局处理程序”来创建新的全局处理。
让我们使用第二个选项并创建全局处理程序。
使用第二种方法的优点是,它为全局处理程序工作流提供了一个起点。
全局处理程序工作流中有两个预定义的参数:errorInfo,存储有关触发处理程序的异常的信息,以及一个result,用于确定进程遇到错误时的行为。
日志消息为异常创建日志。我们可以定制它。让我们仅显示异常消息,而不是所有详细信息。我们可以通过向表达式中添加Message属性来实现这一点。
在下面的部分中,处理程序使用errorInfo
对象的RetryCount
属性来标识活动的重试次数。默认情况下,最大重试次数设置为3。
这两个任务设置下一个要采取的行动。在这种情况下,如果重试次数小于3,则重试,如果达到最大重试次数,则在运行当前处理程序后中止执行。让我们再添加一条日志消息,以查看每个步骤的重试次数。我们可以通过使用errorInfo对象的RetryCount属性来获取该值。
让我们在项目中生成一个异常,以查看全局异常处理程序的行为。我们将尝试将不是有效数字的字符串转换为Int32。
让我们回到Main.XAML并创建一个类型为“Int32”的变量“IntVar”。
让我们添加一个“Assign”活动,并将一个不是有效数字的字符串转换为Int32。
IntVar = Cint(“abc”)
现在,我们将添加2个“日志消息”活动。一个在“分配”活动之前,一个在活动之后。
在第一个“记录消息”活动中,让我们在消息字段中添加“分配活动之前”。
在第二个“记录消息”活动中,让我们在消息字段中添加“分配活动之后”。
首先,我们将在禁用全局处理程序的情况下运行项目,以查看发生了什么。为此,我们将右键单击项目面板中的处理程序工作流,然后选择移除处理程序。让我们保存并运行项目。我们看到错误被抛出。
现在让我们再次启用全局处理程序。我们通过从上下文菜单中选择Set as Global Handler
来完成此操作。
让我们再次运行工作流。由于已达到重试计数,仍会引发错误。让我们看看“输出”面板。
我们看到错误的Assign活动已经执行了4次。第一次尝试加上三次重试。对于第四次尝试,全局处理程序执行了Abort操作,该操作抛出错误并停止执行。
在Global Handler中,有一个assign
活动很重要,我们将ErrorAction
属性设置为结果参数。它可以是“继续”、“忽略”、“重试”或“中止”。如果我们在全局处理程序中不使用任何这样的分配,则使用的默认操作是Continue,这将重新引发异常。
让我们更改Handler的行为。这一次,我们希望选择忽略错误。为此,我们将把Assign活动拖到If活动之外,并删除If。我们将只保留一个赋值,并对ErrorAction参数使用Ignore。
让我们保存处理程序工作流并转到主工作流。现在让我们运行工作流。
我们看到错误被忽略。虽然它是被记录的,因为我们在全局处理程序中使用了日志消息。该错误没有被抛出,并且不会妨碍执行,正如我们在Assign活动之后看到的消息。
我们将了解如何配置全局异常处理程序,以让并排用户决定在有人参与的场景中遇到异常时应采取的操作。
我们将在Main中构建一个非常简单的工作流,以触发错误并进行演示。
我们将添加工作簿“读取范围”活动以从Excel文件中读取信息。
让我们在读取范围活动前后添加两条日志消息。
现在,让我们向项目中添加一个全局处理程序。我们将在处理程序工作流的开头记录异常消息。
接下来,我们将请求用户输入Handler要执行的操作。
因此,让我们添加一个“输入对话框”活动。
让我们添加一个标题,然后将“输入类型”设置为“多选”。我们想让用户可以在继续、忽略、重试和中止之间进行选择。我们将在“输入选项”属性字段中添加这些选项。
在输入标签中,我们希望向用户显示错误消息,以便他们知道问题所在。我们可以使用表达式errorInfo.Exception.message来实现这一点。
我们将用户选择存储在一个新变量“UserChoice”中。接下来,让我们添加一个Switch活动,它将根据用户选择设置结果参数。
我们将使用“UserChoice”变量作为输入,然后将“Argument Type”设置为“String”。
接下来,我们将为每个可能的用户选择构建一个案例。在每种情况下,我们都会将相应的错误操作分配给结果参数。
我们将从If语句复制“Assign”活动,并将其粘贴到“Continue”案例中。
让我们将Value修改为“errorAction.Continue”。让我们对“忽略”、“重试”和“中止”选项重复此操作。
好啊我们已经完成了Handler的配置。
请记住,在主工作流中,我们正在使用工作簿读取范围活动读取Excel文件。
让我们打开Excel文件,以便在运行时得到错误,然后处理程序介入。让我们保存并运行工作流。
已触发处理程序。让我们测试一些选项。我们将选择“忽略”。
在输出面板中,我们可以看到我们登录到全局处理程序的错误消息。
请注意,Main中的最后一个日志消息活动已被执行,因为该错误已被忽略,并且运行已完成。
让我们再次运行工作流,并选择“重试”。由于Excel文件仍处于打开状态,因此将再次触发Handler。
让我们关闭Excel文件并重试。我们看到,自问题解决后,工作流已完成执行。
在输出面板中,我们有一个第一次出现错误的日志,然后有两个额外的日志,用于我们尝试的两次重试。
Try包含我们怀疑可能引发异常的活动。
Catches允许我们为多个异常类型配置案例。最常见的是系统异常。如果捕获的异常对应于Catches块中的父类型和子类型,则执行最具体的情况。
Finally保存一个活动,该活动仅在未发生错误或已捕获错误时执行。
当我们想要抛出异常时,我们使用Throw活动,即使它不是由活动生成的。它通常用于定义业务规则例外。
我们只能在catch块内使用Rethrow活动,并将再次抛出最初捕获的异常。
Retry Scope主要优点
其功能介于try-catch和do-while循环之间。
它在操作部分中执行错误处理。如果出现错误,它将在错误发生的地方停止。它将等待设定的持续时间。否则,它将等待五秒钟,然后重试并消耗该读数。
NumberOfRetries只是操作序列可以运行的最大数量。如果NumberOfRetries设置为2,它将只重试一次,因此该操作总共执行两次。
RetryInterval指定每次重试之间的时间量。
条件可以有零个或一个活动,如果选中的条件为False,则将有另一个重试。如果检查的条件为True,则不会再次重试。
全局异常处理程序是一种工作流,用于在遇到执行错误时确定项目的行为。每个自动化项目只能设置一个全局异常处理程序。
全局异常处理程序有两个不应删除的参数。
我们可以通过在Handler工作流中使用一个多选输入对话框,让用户在Continue、Ignore、Retry和Abort之间进行选择。然后,我们将相应的操作分配给Switch活动内的结果参数。
Global Exception Handler
App Integration
TryCatch
Logging Levels
Retry Scope
UI Activities Properties
UiPath Forum: RPA Developer Foundation Training - Feedback Space
UiPath Forum: Exception Handling Topic
⭐写在结尾:
文章中出现的任何错误请大家批评指出,一定及时修改。
希望写在这里的小伙伴能给个三连支持!