|
|
谈易语言的异常处理，很多人第一反应是“写个判断、弹个对话框就完事了”。但真把项目跑到用户机器上，你会发现：错误并不止是“有没有文件”这么简单，更多是资源状态不一致、线程中断、COM/WinAPI返回码模棱两可、以及用户误操作叠加导致的连锁反应。异常处理与错误恢复，核心不在“把报错藏起来”，而是在出错后仍能把程序带回一个可预期的稳定状态。
先说机制层面。易语言既有过程返回值/标志位的“显式错误码”风格，也支持类似“异常块”的捕获思路（很多库函数失败后会设置错误信息，可通过相关函数取回）。我自己的做法是将“错误来源”分三级：可预期的业务校验（例如参数为空、路径不存在）、系统性故障（磁盘满、权限不足、网络断连）、编程缺陷（下标越界、空指针）。第一级用分支与早返回最清晰；第二级要集中封装（统一重试、降级、回退）；第三级必须在开发期尽量暴露（断言与日志）而在发布版用兜底捕获防止崩溃。
容易被忽略的是“幂等性”。所谓恢复，前提是你的操作可安全重试。例如写配置文件时，先写到临时文件，再原子替换；数据库更新要么用事务，要么把多步操作封在同一逻辑里，任何一步失败都能整体回滚。网络调用要带请求标识，防止重复提交造成脏数据。没有幂等保障，所谓“重试三次”只会把问题放大。
另一个关键是“失败即资源自洽”。资源的申请与释放要么同域管理，要么用退出路径统一收尾。比如创建窗口句柄、打开文件、分配内存，只要任一步失败，都要把已获得的资源成对释放，避免泄漏导致后续莫名其妙的“系统忙碌”类错误。
日志与可观测性也很关键。别只在出错时弹出“发生错误(5)”，这对用户和你都没价值。建议最少记录：时间戳、线程ID、调用点、输入参数摘要、外部依赖状态（网络、磁盘余量、当前用户/权限）、以及最近一次系统错误码。日志级别要分清：DEBUG用于开发定位，INFO记录关键业务里程碑，WARN用于可恢复异常，ERROR用于需人工介入的问题。发布版默认INFO+WARN，出问题再让用户切到DEBUG重现。日志不要阻塞主流程，最好采用缓冲+后台写入，并限制单日体量，避免“写日志写到磁盘满”的自戕。
关于用户交互层的错误恢复，我的经验是：在必要时给出三选项——重试、改设置、稍后处理。比如导出失败，直接提供“更换目录再试”的入口而不是一句“失败了请联系管理员”。同时要把“已完成进度”讲清楚，例如“已导出12/50，失败于第13个文件”，并支持从断点继续。对长耗时任务，进度条和可取消是基本礼仪，取消后要保证状态回滚到起点或稳定中间态，而不是夹在半拉子里。
线程与异步是另一个坑点。易语言里很多人习惯把繁重IO丢到子线程，但异常却只在子线程里默默吞掉。建议约定统一的异步任务包装：捕获所有异常，封装为结果对象返回主线程，由主线程统一决策UI提示、重试策略和回退逻辑。配合“熔断”与“退避重试”（指数+抖动）可避免对不稳定服务的风暴式请求。记得在取消或失败路径上，确保对共享状态的更新具备原子性，必要时加互斥或使用消息队列解耦。
具体策略可以落到几条可操作的规范：
- 入口即校验：所有公开过程先校验参数，失败早返回，错误码清晰可判。
- 有副作用的操作必须具备幂等设计：临时文件+原子替换、事务或补偿动作。
- 错误集中翻译：底层把WinAPI/COM错误映射到统一错误域，携带上下文，便于上层策略化处理。
- 默认不重试，除非证明安全且收益大；一旦重试，必须有上限与退避。
- 任何资源获取都要有对应释放点；在异常路径走通前，先写出“清理表”。
- UI文案面向任务，而非技术细节；技术细节进日志，任务层面给可行选项。
测试层面，别只跑“成功路径”。构造失败注入：模拟磁盘满、网络抖动、权限不足、第三方返回畸形数据。对每个失败点，验证三件事：是否被正确识别、是否给出预期的恢复选项、是否保持状态一致。可以把关键外部调用替换为可控的“故障桩”，用概率或脚本触发超时/半包/乱序，逼出边界问题。
最后说心态。异常处理不是为“永不报错”，而是为“错误不毁灭体验”。当你能在失败后几步内把系统拉回可预期轨道，用户会把这当作产品可靠性的底色。对易语言项目而言，把错误码文化、幂等设计、集中化恢复策略和高质量日志，变成团队的共同约定，这套机制就算立起来了。链接层面，不妨把团队约定、错误码表和常见恢复剧本写成一页在线文档，直接在程序里“更多信息”跳转过去，既减轻支持压力，也能让用户看到你对稳定性的认真态度。 |
|
发表于 
微信公众号
官方抖音号