企业级报表引擎需将try-catch下沉至公式解析器与求值器内部，按失败类型分级兜底，并通过finally统一埋点、formula_errors透传错误至前端实现可观测与用户联动。

在企业级报表引擎中，异步公式解析失败往往表现为字段空白、数值错乱或整个报表卡死——这通常不是公式写错了，而是解析过程中遭遇空值、类型不匹配、网络延迟或权限中断等运行时异常。单纯依赖外部重试或人工刷新无法根治问题，必须把 try-catch 机制下沉到公式执行引擎内部，实现“失败可感知、错误可定位、结果可兜底”的闭环。

把 catch 嵌入公式执行上下文，而非包裹整个报表渲染

很多团队误将 try-catch 加在模板层（比如用 JavaScript 模板语法包一层），但这对异步公式无效：公式可能由后端表达式引擎（如 DAX、自研 DSL）异步编译执行，前端模板根本不在其调用栈内。真正有效的做法是：

• 在公式解析器（Parser）和求值器（Evaluator）的每个关键节点插入内部 try-catch，例如：字段路径导航、函数调用、类型转换、聚合计算
• catch 块不吞异常，而是捕获后立即注入统一错误上下文：当前公式文本、数据源标识、执行阶段（parse/eval/serialize）、trace_id
• 将错误结构化写入报表状态对象（如 state.formulaErrors["sales.total"] = { code: "TYPE_MISMATCH", value: null }），供后续可视化或日志系统消费

区分三类失败，执行差异化兜底策略

不是所有解析失败都该返回“-”或“0”。需按语义分级处理：

• 瞬时性失败（如远程维度服务超时、缓存未命中）→ 触发本地缓存值 + 标记“待刷新”，不阻断渲染
• 数据缺陷型失败（如 JSON 字段缺失、数字字段含字符串）→ 返回空值并记录字段级错误码，支持运维一键跳转至原始数据行
• 权限或配置错误（如用户无权访问某指标、公式引用已下线的自定义函数）→ 阻断该字段，返回带操作指引的提示（如“请联系管理员开通【销售额】指标权限”）

让 finally 成为可观测性入口，而非清理收尾

报表引擎中的 finally 块常被用来释放表达式上下文或清空临时变量，但更关键的作用是统一埋点：

• 无论公式成功或失败，finally 都上报耗时、是否命中缓存、最终输出类型（number/string/array/null）
• 对失败 case，额外透传 error.code 和 error.path（如 "user.profile.phone"），支撑按字段聚合错误率
• 禁止在 finally 中执行任何可能抛异常的操作（如写磁盘、调用未兜底的 SDK），若必须执行，内部再套一层 try-catch 并仅记录日志

与前端联动，实现错误从引擎直达用户

内部 catch 捕获的错误不应只停留在服务端日志里。需通过标准协议透出给前端：

• 响应体中固定携带 formula_errors 字段，结构为 {"sales.total": {"code": "DIV_BY_ZERO", "message": "分母为零"}}
• 前端根据 error.code 显示不同样式：红色叹号图标（权限类）、灰色破折号（数据缺失）、黄色感叹号（计算警告）
• 支持点击错误提示展开原始公式、上游数据快照、最近一次成功值对比，降低排查门槛