影刀RPA异常处理实战：Try-Catch正确用法

影刀RPA异常处理实战：Try-Catch正确用法

作者：林焱 | 难度：⭐⭐⭐ | 预计阅读：11分钟

写在前面

没有哪个RPA流程能永远不报错。

网络会抖，页面会改版，弹窗会乱入，元素会失效。

如果不在流程里加入异常处理，任何一个意外都会导致整个流程中断，前面跑的数据全白费。

这篇文章把Try-Catch讲透——什么时候用、怎么用、Finally块到底有什么用。

一、RPA流程里会遇到哪些异常？

先搞清楚：异常有哪些类型，才能知道怎么处理。

可控异常

这类异常是可以提前预判的。

比如：

• 账号或密码错误
• 文件不存在
• Excel被其他程序占用
• 某个必填参数没有传值

可控异常的特点是：你事先知道"这种情况可能发生"，可以提前写逻辑判断。

处理方式：用If/Else判断，提前拦截。

不可控异常

这类异常无法提前预判，是运行时才出现的。

比如：

• 网络突然断了

• 页面上突然弹出一个广告弹窗

• 元素突然找不到了（网页改版）

• 服务器超时无响应

不可控异常的特点是：你不知道它什么时候会发生。

处理方式：用Try-Catch捕获，防止流程崩溃。

二、Try-Catch的基本结构

Try-Catch是影刀RPA里处理异常的核心指令。

基本结构：

Try 可能出错的指令... Catch 出错后要执行的逻辑... Finally 无论是否出错，都会执行的清理逻辑... End Try

三个块分别做什么？

Try块：放可能出错的指令。

比如：打开网页、点击元素、读取文件……这些操作都有可能失败，放在Try里。

Catch块：放出错后的处理逻辑。

比如：截图保存现场、写日志、发通知给管理员、给变量赋一个默认值……

Finally块：放无论如何都要执行的清理逻辑。

比如：关闭浏览器、关闭Excel、释放资源……

关键：即使Try块里执行了终止应用，Finally块仍然会执行。

三、Try-Catch实战案例

案例1：打开网页时处理超时

网络不好的时候，打开网页指令可能会超时或失败。

Try 打开网页（URL：https://www.example.com，超时：10秒） [等待元素出现]（元素：页面加载完成标志，超时：5秒） Catch 打印日志："打开网页失败，原因：" + ${exception_message} 截图（保存路径：./logs/error_screenshot.png） 发送钉钉通知（内容："流程异常：打开网页失败"） 给变量 ${page_load_success} 赋值：false Finally 如果（${page_load_success} == false） 关闭网页 结束如果 End Try

案例2：采集数据时处理元素找不到

采集列表数据时，如果某一条数据的元素突然找不到了（比如被删除或改版），整个循环就会中断。

用Try-Catch包裹每次采集操作，可以保证一条失败不影响其他条。

循环（ForEach，item in ${product_list}） Try 获取元素文本（目标元素：商品标题）→ 保存到 ${title} 获取元素文本（目标元素：商品价格）→ 保存到 ${price} 写入Excel（行：当前行，列1：${title}，列2：${price}） Catch 打印日志："采集第" + ${index} + "条数据失败，跳过") 继续循环 ← 关键：跳过当前条，继续下一条 End Try 结束循环

四、Try-Catch的常见误区

误区1：Catch块里什么都不写

有些新手会把Catch块留空——什么逻辑都不写。

这样做的结果是：异常被"吞掉"了，你根本不知道流程出了什么问题。

正确做法：至少在Catch块里写日志，记录异常信息。

Catch 打印日志："异常信息：" + ${exception_message}) 截图（保存路径：./logs/error.png）

误区2：Finally块里放业务逻辑

Finally块的本来用途是清理资源（关闭文件、关闭浏览器等）。

有些新手会在Finally里放业务逻辑，比如"写入Excel"。

这样做的问题是：Finally无论如何都会执行——即使Try里已经正常完成了业务逻辑，结果Finally里又执行了一遍，导致重复。

正确做法：Finally里只放清理逻辑，不放业务逻辑。

误区3：Try块里放太多指令

Try块的粒度要合适——不要太大，也不要太小。

太大：一出异常，你不知道具体是哪条指令出的问题。

太小：到处都是Try-Catch，流程看起来很乱。

建议：Try块里放一个完整的功能单元，比如"打开网页并等待加载完成"，这一个单元包在一个Try里。

五、可控异常用If判断，不要用Try-Catch

前面说了，异常分两类：可控和不可控。

可控异常应该用If判断来处理，不要用Try-Catch。

举例：检查文件是否存在

错误做法（用Try-Catch）：

Try 打开Excel文件（路径：${file_path}） Catch 打印日志："文件不存在" End Try

正确做法（用If判断）：

If（文件是否存在（${file_path}）== true） 打开Excel文件（路径：${file_path}） Else 打印日志："文件不存在，请检查路径：" + ${file_path} 终止应用 End If

原因：文件是否存在，是可以提前判断的，不需要等到运行时才捕获异常。

提前判断，逻辑更清晰，效率也更高。

六、异常信息的获取

在Catch块里，你可以获取详细的异常信息，帮助你定位问题。

影刀RPA提供了以下内置变量（在Catch块里自动可用）：

实战：把异常信息写到日志文件

Catch 拼接字符串（结果：${error_log}，内容："[" + 时间字符串（现在） + "] 异常类型：" + ${exception_type} + "，异常信息：" + ${exception_message}） 写入文本文件（文件路径：./logs/error.log，内容：${error_log}，追加模式）

七、多层Try-Catch：异常向上抛出

有时候，子流程A调用了子流程B，而异常发生在子流程B里。

这时候有两种处理方式：

方式1：在子流程B里处理异常

子流程B自己用Try-Catch把异常处理掉，子流程A完全不知道发生过异常。

适用场景：这个异常子流程B自己就能处理，不需要告诉调用方。

方式2：在子流程B里不处理，让异常"抛"给子流程A

子流程B里不用Try-Catch，让异常自然抛出。

子流程A调用子流程B时，用Try-Catch包裹，在Catch里统一处理。

适用场景：这个异常需要调用方来决定怎么处理（比如：是重试、还是终止、还是通知管理员）。

代码示例

子流程B（被调用方）：不进行异常处理，让异常抛出。

子流程B：采集商品标题 1. 获取元素文本（目标元素：商品标题）→ 保存到 ${title} 2. 返回 ${title}

子流程A（调用方）：用Try-Catch包裹调用。

Try 调用子流程：采集商品标题（输出：${result_title}） Catch 打印日志："采集商品标题失败：" + ${exception_message}") 给 ${result_title} 赋值："采集失败" Finally （清理逻辑） End Try

八、实战：一个健壮的数据采集流程

把前面讲的所有异常处理技巧，整合到一个完整的流程里。

流程结构

主流程 main ├── Try │ ├── 调用子流程：初始化（打开网页、校验登录状态） │ ├── 调用子流程：采集数据（循环采集每一条） │ └── 调用子流程：保存数据（写入Excel） │ Catch │ ├── 截图保存现场 │ ├── 写错误日志 │ └── 发送通知 │ Finally │ ├── 关闭网页 │ ├── 关闭Excel │ └── 打印日志："流程执行完成（无论成功或失败）" └── End Try

关键点

1. 主流程只包一个大的Try-Catch，保证任何未捕获的异常都不会导致流程无声崩溃。

2. 每个子流程内部，也根据自己的需要加Try-Catch。比如"采集数据"子流程里，每一条数据的采集都用Try-Catch包裹，保证一条失败不影响其他条。

3. Finally块里做清理，确保无论成功还是失败，资源都会被释放。

九、常见异常速查表

十、结语

异常处理的核心目标只有一个：

让流程在遇到意外时，能够优雅地处理，而不是直接崩溃。

Try-Catch用好了，你的流程会健壮很多。

回头看最重要的一句：

可控异常用If判断，不可控异常用Try-Catch。

把这个原则记住，异常处理就不会乱用了。

下一篇讲数据采集实战，把循环、Excel写入、异常处理整合到一个完整案例里。

作者：林焱 | 转载请注明出处