子类化异常

在良好的实践中,不是真的。。。不过,如果你愿意的话,你可以做一些黑客攻击 真正地

例如,这些黑客之一是 eval 这些类通过自动加载器进入存在。这很糟糕,因为如果有人 grep 对于异常的定义,或者对于包抛出的异常,它们将是一大堆nada作为回报。。。

public static function load($name) {
    $parts = explode('_', $name);
    if (strtolower(end($parts)) == 'exception') {
        //make it extend the proper exception
        array_pop($parts); //get rid of the last Exception bit
        array_pop($parts);
        $parts[] = 'Exception';
        $parent = implode('_', $parts);
        $code = 'class '.$name.' extends '.$parent . '{}';
        eval($code);
    }
}

就我个人而言,我继承了多个“基本异常”(通常是 SPL exceptions ). 举个例子 Database_Connection_Exception 可能延伸 RuntimeException ,尝试提交未打开的事务可能会引发 Database_Not_In_Transaction_Exception 可能会延长 LogicException . 关键是单独声明它们可以让您做的不仅仅是直接的heiarchal继承(更不用说对于文档来说更好了,因为人们可以看一眼定义的异常,如果合适的话,您实际上可以重写方法以更好地满足您的需要)。。。

编辑: 根据你提到的 Zend

基本上,我有一些在整个应用程序中使用的“全局”异常。包括(但不限于): ClassNotFoundException FileNotFoundException , NotCallableException 还有其他一些。基本上只是那些不是特定于包的,但是需要传达比核心PHP异常更多的含义。。。

然后,我只在包级别声明异常。在那个目录里( package/exceptions )我宣布每一个例外都是必要的。因此,一个子包可能有5或10个例外来区分不同的情况,而另一个子包(在同一个包内)可能没有例外。所以我根据需要声明它们,这样异常就意味着发生了什么。

我这么做的原因很简单。我才不管呢 where why

你似乎把注意力集中在这些是“幽灵”类的概念上——没有实现的类,或者没有标记接口的类。坦白说,你没抓住重点。

• 全局级别(捕获“异常”)
• 组件级(捕获组件级异常)

这只比简单地到处抛出“Exception”要好一点;您需要仔细检查异常消息以了解哪里出了问题。

现在,去仔细阅读这个提议。

• 不管是什么例外?捕获\异常。
• 要捕获组件中的特定异常类型吗?抓住它。

基本上,我们只在例外情况下允许更大的粒度 类型 现在,如果尝试的操作可能引发多个相同类型的异常,则只需检查消息。通常情况下,情况不应该是这样。

有些人使用 autoloader 动态创建异常。

Zend_Exception 所有的方式,但这只会使你的异常太一般,将很难找到原因,在尝试..捕捉

--当您调用它们时——主要是在“包”级别上,或者当一个方法被期望抛出一个或另一个异常时(因此我可以捕获这个非常特殊的异常并相应地处理它)。

重影文件 但它只会让你的项目更有条理,最终更容易调试。而且,由于这些异常只在需要的基础上加载,所以拥有大量的异常不会影响性能。

here this post on php exceptions