调用apex_custom_auth.post_login遇APEX.PROCESS.UNHANDLED_ERROR，求错误类型判断

结合你提供的错误信息，可通过以下步骤判断错误类型并排查：

1. 解析错误标记与调用栈 #

• 错误中is_internal_error: true说明APEX框架标记这是内部错误，但这不代表完全和你的代码无关——很多时候是自定义代码触发了框架内部的未处理异常。
• 调用栈显示错误来自APEX_230100.WWV_FLOW_PROCESS（APEX核心处理包），但当前调用栈仅到内部包，需要开启更详细的调试来捕捉完整调用链路，确认触发错误的源头是否为你的PL/SQL代码。

2. 关联错误发生的组件 #

错误的component.type: APEX_APPLICATION_PAGES和component.name: Register明确指出，错误发生在你自定义的「Register」页面的处理流程中。这意味着大概率是页面上的PL/SQL逻辑（比如调用apex_custom_auth.post_login的代码）触发了框架内部的异常。

3. 强化自定义PL/SQL代码的异常追踪 #

针对页面上所有自定义PL/SQL块（尤其是调用apex_custom_auth.post_login的部分），添加完整的异常处理逻辑以记录详细错误栈：

BEGIN
  -- 你的业务逻辑，示例调用apex_custom_auth.post_login
  apex_custom_auth.post_login(
    p_uname => :P1_USERNAME,
    p_session_id => :APP_SESSION,
    p_app_page => :APP_ID || ':' || :APP_PAGE_ID
  );
EXCEPTION
  WHEN OTHERS THEN
    -- 记录完整错误信息到APEX调试日志
    apex_debug.message('错误信息: ' || SQLERRM || ' 调用栈: ' || dbms_utility.format_error_backtrace());
    RAISE; -- 重新抛出异常，不打断原有错误流程
END;

通过这种方式，你可以明确是否是自己的代码（比如未处理的SELECT INTO查询）先抛出NO_DATA_FOUND，进而触发了APEX内部的错误处理逻辑。

4. 验证apex_custom_auth.post_login的参数有效性 #

apex_custom_auth.post_login的参数不符合要求时，会触发APEX内部的查询异常：

• 确认传入的p_uname对应用户在APEX用户表（如APEX_WORKSPACE_APEX_USERS或自定义用户表）中存在；
• 检查会话ID、应用页面ID等参数是否正确传递，避免因参数无效导致框架内部查询无数据返回。

5. 排查APEX版本已知问题 #

你使用的是APEX 23.1版本，可查阅官方文档确认该版本中apex_custom_auth.post_login是否存在已知BUG，或是否有未被满足的特定使用限制。

内容的提问来源于stack exchange，提问作者Santosh Bhoir