一、异常处理基础：什么是异常？为什么RPA中需要异常处理？异常处理的核心思想

1.1 异常到底是什么？

异常，说白了就是程序运行过程中出现的「意外状况」。

我举个例子。你写了一个RPA脚本，让它自动登录系统。正常情况下，输入账号密码、点击登录、进入主页，一气呵成。但某天系统弹了个验证码——脚本不认识，直接卡住了。这就是异常。

在编程世界里，异常是一个对象。它包含了错误类型、错误描述、错误发生的位置等信息。RPA工具（比如UiPath、影刀、实在RPA）都内置了异常对象，你可以在流程中捕获它、分析它、处理它。

1.2 为什么RPA中必须处理异常？

这个问题我问过不少刚入行的朋友。他们的第一反应是：「我脚本写得很稳啊，不会出错的。」

嗯，我年轻时也这么想。直到有一次，我负责的财务对账机器人跑了整整一夜，第二天一看——卡在某个弹窗上，后面几百笔业务全没处理。老板的脸色，你懂的。

RPA和普通软件开发有个本质区别：RPA操作的是真实的应用界面。这意味着你面对的是不可控的环境：

• 网络突然断了
• 系统弹出了意料之外的对话框
• 页面加载超时
• 某个按钮被遮挡了
• 数据格式突然变了

这些情况，你写脚本时根本预测不到。但如果不处理，机器人就会「死」在那里。

1.3 异常处理的核心思想

异常处理不是「出了问题再补救」，而是一种防御性编程思维。我总结了三个核心思想：

思想一：不要假设一切正常

很多新手写RPA时，默认「点击按钮一定会成功」「读取数据一定存在」。这是最危险的想法。

正确的做法是：对每一步操作都问一句「如果失败了怎么办？」

比如点击按钮前，先检查按钮是否存在。读取数据后，先判断数据是否为空。这些检查看似多余，但能救你一命。

思想二：异常要分级处理

不是所有异常都需要同样的处理方式。我习惯把异常分成三类：

异常级别	典型场景	处理方式
可恢复异常	页面加载超时、弹窗干扰	重试、关闭弹窗后继续
需人工介入	数据格式错误、系统崩溃	记录日志、发送通知、暂停流程
致命异常	应用未安装、权限不足	终止流程、上报错误

你想想看，如果所有异常都直接终止流程，那机器人可能一天要停十次。但如果所有异常都自动重试，遇到致命错误时又会无限循环。所以分级处理很关键。

思想三：异常信息要完整保留

异常发生不可怕，可怕的是你不知道为什么发生。

我见过最糟糕的情况：日志里只写了「发生错误」。然后呢？什么信息都没有。排查问题全靠猜。

正确的做法是：捕获异常时，把错误类型、错误描述、堆栈信息、当前操作步骤、截图、数据快照全部记录下来。这样出了问题，你一看日志就知道怎么回事。

1.4 一个简单的异常处理示例

说了这么多理论，来看个实际代码。以UiPath为例，一个带异常处理的登录流程大概长这样：

Try
    // 尝试打开浏览器
    Open Browser "https://example.com"
    
    // 输入账号
    Type Into "username_field" "admin"
    
    // 输入密码
    Type Into "password_field" "123456"
    
    // 点击登录
    Click "login_button"
    
    // 等待页面加载
    Wait For Element "main_page" 10
    
Catch Exception ex
    // 记录异常信息
    Log Message "登录失败: " + ex.Message
    Take Screenshot
    Save Variables To File
    
    // 判断异常类型
    If ex.GetType().Name = "TimeoutException" Then
        // 超时异常，重试一次
        Retry Current Activity
    Else
        // 其他异常，发通知给管理员
        Send Email "admin@company.com" "登录异常"
        Stop Process
    End If
Finally
    // 无论成功失败，都关闭浏览器
    Close Browser
End Try

这段代码展示了异常处理的完整结构：

• Try块：放正常流程
• Catch块：捕获并处理异常
• Finally块：做清理工作（关闭资源、释放句柄）

1.5 异常处理的核心原则

最后，我总结几条原则，你写RPA时可以贴在工位上：

1. 早捕获，早处理——异常越早处理，影响范围越小
2. 不要吞异常——捕获了却不处理，等于掩耳盗铃
3. 日志要详细——你永远不知道排查问题时需要什么信息
4. 要有兜底方案——所有异常处理都失败时，至少能通知到人
5. 测试异常路径——别只测正常流程，故意制造异常来验证处理逻辑

下一章，我会详细讲RPA中常见的异常类型，以及每种异常该怎么处理。到时候我会分享一些实际项目中踩过的坑，保证让你少走弯路。