PHP 8.5用get_exception_handler读取处理器

PHP 8.5 的 get_exception_handler() 无参数调用即可读取当前用户异常处理器，返回注册时传入的 callable；当前没有用户处理器时返回 null。读取操作不会执行回调，也不需要临时替换处理器，适合定位应用启动期间的注册覆盖。

设想一个排障场景：接入扩展后，未捕获异常的日志出口与原来不同。先不要重新注册应用处理器来“试着修复”，应在可疑初始化阶段前后读取状态，确认究竟是处理器变化，还是框架已经在更早的位置捕获异常。以下是原创演示场景，不是实际事故报告。

PHP 官方地址：https://www.php.net/

从异常输出变化确定观察范围

将问题范围限定在同一运行入口：Web请求、CLI命令和长期运行任务可能拥有不同的启动代码。把“哪里注册处理器”和“哪里观察到异常输出”对应起来，再沿应用初始化阶段记录状态。

例如，假设应用启动阶段注册了 application handler，扩展初始化又注册 extension handler，那么后注册者会成为当前处理器。这个假设需要通过程序状态确认，不能因为新增了某个依赖就直接把责任归给它。

PHP 8.5新增函数列表：https://www.php.net/manual/en/migration85.new-functions.php

用最小读取函数记录当前回调

下面片段可作为启动阶段的简单观察点。它只区分返回值类别；多个不同闭包都会显示 Closure，所以类别相同不能证明是同一个处理器。

如果应用保存着自己注册的闭包，可以把返回值与该闭包变量作严格比较。若注册形式是函数名称、方法数组或可调用对象，则按实际 callable 形式解释，不要为了比较而随意转换表示形式。

官方 getter 文档：https://www.php.net/manual/en/function.get-exception-handler.php

定位初始化阶段的处理器覆盖

下面是一份独立CLI示例。两个不同闭包分别代表应用和扩展，通过受控嵌套注册展示如何比较覆盖前后的处理器。代码没有抛出未捕获异常，不会把“读取状态”与“实际触发异常出口”混在一起。

按示例语义，四个判断应均为 yes。它们依次表达应用闭包被读取、扩展闭包成为当前值、应用状态被恢复以及入口状态被归还。这里描述预期行为，不声称已经在本地执行。

真实应用可以在框架引导、扩展加载和工作任务启动等位置设置观察点。只在观察值发生变化的相邻阶段继续缩小范围，而不是在每个业务方法里反复记录整个回调对象。日志应尽量记录阶段标识与已知处理器名称，避免导出闭包捕获的业务数据。

在受控注册范围内成对恢复

set_exception_handler() 改变当前用户处理器，并返回先前的处理器；restore_exception_handler() 用于撤回注册并恢复上一层。示例中的 finally 对应各自的一次注册，便于看清谁负责释放这一层状态。

官方注册说明：https://www.php.net/manual/en/function.set-exception-handler.php

官方恢复说明：https://www.php.net/manual/en/function.restore-exception-handler.php

这种配对写法有前提：受控范围内没有第三方私自改变注册层次。不能把任意插件执行包进 finally，然后假设一次 restore 就能撤销它的全部行为。应用集成应先明确处理器归属，再决定由哪个组件拥有注册与恢复责任。

区分 null、异常触发与兼容问题

未捕获异常才会进入默认异常处理器，已被 try/catch 捕获的异常不会因此转交给它。处理器返回也不意味着程序会从原来的 throw 位置继续执行，所以不要在待恢复的业务流程中靠全局处理器完成常规控制。

还有一个容易误判的特殊位置：PHP 8.3起，引擎在调用异常处理器时会暂时取消其活动状态。因此，不应在处理器内部读取到 null 后断言应用从未注册过处理器，也不应在该位置随意改动注册栈。本例刻意只在普通执行位置观察。

旧版本若没有该函数，最保守的诊断方式是明确记录“getter unavailable”，同时由应用集中保存自己注册的处理器信息。不要把临时 set/restore 的模拟读取和 PHP 8.5 原生的只读观察视为完全相同的集成行为。

固定注册所有权防止再次覆盖

修复应落在可解释的初始化关系上：由一个明确的应用入口负责最终注册；扩展通过约定接口接入日志与响应；临时注册者承担恢复责任。若框架已经集中管理异常出口，优先使用框架扩展点，避免另建一套并行机制。

读取后需要调用 restore 吗？不需要。getter 没有进行注册，不能为一次读取额外弹出处理器。

能否调用返回值来确认它有效？不应把手动调用当作读取步骤。回调可能写日志或生成响应，执行它会产生副作用；状态读取与行为测试应分开设计。

为什么处理器看起来正确，异常仍没进入它？先确认异常是否已被框架或业务捕获，再确认观察与异常属于同一运行入口及同一阶段；getter 只回答当前注册状态。