Oracle EBS ERP开发 — 抛出异常EXCEPTION书写规范

        在Oracle EBS ERP接口开发中，异常处理（EXCEPTION）是确保系统稳定性和可维护性的关键环节。规范的异常处理不仅能有效捕获错误，还能提供清晰的错误信息，便于问题排查和系统维护。 

一：不规范 

log_msg(' 下载PLM表开始>>>');
BEGIN
  EXECUTE IMMEDIATE 'drop table cux_plm_item_0';
EXCEPTION
  WHEN OTHERS THEN
    NULL; -- 不规范的异常处理：静默忽略所有错误
END;
BEGIN
  EXECUTE IMMEDIATE 'create table cux_plm_item_0 as select * from item_0@plm_link ';
  EXECUTE IMMEDIATE 'create index cux_plm_item_0_n1 on cux_plm_item_0(md_id) ';
  EXECUTE IMMEDIATE 'create index cux_plm_item_0_n2 on cux_plm_item_0(status) ';
EXCEPTION
  WHEN OTHERS THEN
    NULL; -- 不规范的异常处理：静默忽略所有错误
END;
log_msg(' 下载PLM表结束<<<');

问题分析：

1. 异常处理块中只有NULL语句，完全忽略所有错误
2. 没有记录错误日志，无法追踪问题
3. 没有设置错误状态和错误信息
4. 没有中断程序执行，可能导致后续操作基于错误状态继续运行

二：规范 

log_msg(' 下载PLM表开始>>>');
BEGIN
  EXECUTE IMMEDIATE 'drop table cux_plm_item_0';
EXCEPTION
  WHEN OTHERS THEN
    NULL; -- 删除表失败可以忽略（表可能不存在）
END;
BEGIN
  EXECUTE IMMEDIATE 'create table cux_plm_item_0 as select * from item_0@plm_link ';
  EXECUTE IMMEDIATE 'create index cux_plm_item_0_n1 on cux_plm_item_0(md_id) ';
  EXECUTE IMMEDIATE 'create index cux_plm_item_0_n2 on cux_plm_item_0(status) ';
EXCEPTION
  WHEN OTHERS THEN
    -- 1. 定义状态为错误和填写错误信息
    xv_return_status := fnd_api.g_ret_sts_error;
    xv_msg_data      := '下载PLM表cux_plm_item_0出现错误.'|| SQLCODE || ' ' ||SQLERRM;
    
    -- 2. 对报错的代码重新以正确的方式执行
   EXECUTE IMMEDIATE 'create table cux_plm_item_0 as select * from DUAL ';
   EXECUTE IMMEDIATE 'create index cux_plm_item_0_n1 on cux_plm_item_0(md_id) ';
   EXECUTE IMMEDIATE 'create index cux_plm_item_0_n2 on cux_plm_item_0(status) ';
    
    -- 3. 日志打印错误信息和系统错误信息
    log_msg('下载PLM表cux_plm_item_0出现错误.'|| SQLCODE || ' ' ||SQLERRM);
    
    -- 中断执行
    return;
END;
log_msg(' 下载PLM表结束<<<');

 规范的异常处理三大要素

1. 定义状态为错误和填写错误信息 

在Oracle EBS开发中，标准API通常使用fnd_api.g_ret_sts_error表示错误状态。规范的异常处理应包含：

EXCEPTION
  WHEN OTHERS THEN
    -- 设置返回状态为错误
    xv_return_status := fnd_api.g_ret_sts_error;
    
    -- 填写详细的错误信息
    xv_msg_data := '自定义错误描述' || SQLCODE || ' ' || SQLERRM;

 关键点：

• 使用fnd_api.g_ret_sts_error标准错误状态常量
• 错误信息应包含：业务描述 + 系统错误代码(SQLCODE) + 系统错误描述(SQLERRM)
• 错误信息应存储在标准变量xv_msg_data中供调用方使用

2. 对报错的代码重新以正确的方式执行

当关键操作失败时，应采取适当的补救措施或清理操作：

EXCEPTION
  WHEN OTHERS THEN
    -- 创建空表作为补救措施
    EXECUTE IMMEDIATE 'create table cux_plm_item_0 as select * from DUAL ';
    
    -- 其他可能的补救措施：
    -- - 回滚事务
    -- - 清理临时数据
    -- - 释放资源

关键点：

• 根据业务需求设计合理的补救措施
• 确保补救措施本身不会引发新的异常
• 补救措施应保证系统处于一致状态

3. 日志打印错误信息和系统错误信息

规范的日志记录是问题排查的基础：

EXCEPTION
  WHEN OTHERS THEN
    -- 记录详细错误日志
    log_msg('业务操作描述失败: ' || SQLCODE || ' - ' || SQLERRM);
    
    -- 可选：记录更多上下文信息
    log_msg('当前操作: 下载PLM表cux_plm_item_0');
    log_msg('参数值: p_param1=' || p_param1);

关键点：

• 使用标准日志函数（如log_msg）
• 日志应包含：业务上下文 + 系统错误代码 + 系统错误描述
• 可添加关键参数值帮助定位问题
• 日志级别应合理设置（ERROR级别）