如何批量转换不同命名空间的异常至MyAppException

嘿，这个问题我之前也碰到过——不想到处写重复的try/catch确实是个合理的诉求！咱们来聊聊几个优雅的解决方案，不用动原Callback对象的代码，也能批量转换异常：

这是最干净的实现方式，完全符合开闭原则——不用修改原回调对象的任何代码，只需要新增一个装饰器类来包装它，统一处理异常转换。

举个PHP代码例子，假设你的回调对象实现了一个接口：

namespace MyApp\Callbacks;

use MyApp\MyAppException;
use MyApp\Callbacks\OriginalCallbackInterface;

class CallbackExceptionDecorator implements OriginalCallbackInterface
{
    private $originalCallback;

    // 构造函数注入原回调对象
    public function __construct(OriginalCallbackInterface $originalCallback)
    {
        $this->originalCallback = $originalCallback;
    }

    // 包装原对象的核心方法，捕获异常并转换
    public function execute($input)
    {
        try {
            return $this->originalCallback->execute($input);
        } catch (CallbackException $e) {
            // 保留原异常作为前因，方便后续调试
            throw new MyAppException(
                "回调执行失败: {$e->getMessage()}",
                $e->getCode(),
                $e
            );
        }
    }

    // 如果原对象有多个方法，可以用__call动态处理，避免重复代码
    public function __call($method, $arguments)
    {
        try {
            return call_user_func_array([$this->originalCallback, $method], $arguments);
        } catch (CallbackException $e) {
            throw new MyAppException(
                "回调方法{$method}执行失败: {$e->getMessage()}",
                $e->getCode(),
                $e
            );
        }
    }
}

使用的时候，只需要把原回调对象用装饰器包一层：

// 原来的用法
$callback = new OriginalCallback();

// 现在的用法
$callback = new CallbackExceptionDecorator(new OriginalCallback());

这样所有通过装饰器调用的方法，抛出的CallbackException都会自动转换成MyAppException，原对象的逻辑完全不受影响。

如果你的应用有全局异常捕获机制（比如PHP的set_exception_handler，或者框架自带的全局异常处理），可以在这里统一判断异常类型并转换。

比如PHP原生的全局处理器：

set_exception_handler(function (\Throwable $exception) {
    if ($exception instanceof \MyApp\Callbacks\CallbackException) {
        // 转换异常并重新抛出
        throw new \MyApp\MyAppException(
            "回调异常: {$exception->getMessage()}",
            $exception->getCode(),
            $exception
        );
    }

    // 其他类型异常的处理逻辑
    // ...
});

⚠️ 注意：这个方式是全局生效的，如果你有某些场景需要保留原始的CallbackException，就不太适合用这个方案。

如果你用了依赖注入容器（比如Symfony DI、Laravel容器），可以在容器注册的时候自动给回调对象加上代理/装饰器，这样业务代码里完全感知不到包装逻辑。

以Symfony DI为例，配置文件可以这么写：

services:
    # 注册原回调对象
    MyApp\Callbacks\OriginalCallback: ~

    # 注册装饰器，注入原对象
    MyApp\Callbacks\CallbackExceptionDecorator:
        arguments: ['@MyApp\Callbacks\OriginalCallback']
        # 标记为装饰器，自动替换原服务
        decorates: MyApp\Callbacks\OriginalCallback
        decoration_priority: 10

这样当你从容器里获取OriginalCallback的时候，拿到的其实是已经包装好的CallbackExceptionDecorator，完全不用改业务代码。

总结一下：优先选装饰器模式，它灵活、侵入性低，还能保留原异常的上下文；全局处理器适合完全统一的场景；依赖注入结合代理则是框架环境下的最优解。

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