自定义异常消息:最佳实践

时间:2009-03-09 23:17:41

标签: php exception

想知道在创建异常消息时应该多少努力强制使用有用的调试信息,或者我应该只是信任用户提供正确的信息,或者将信息收集推迟到异常处理程序?

我看到很多人都在做例外情况:

throw new RuntimeException('MyObject is not an array')

或使用自定义异常扩展默认异常但不会做太多但只更改异常名称:

throw new WrongTypeException('MyObject is not an array')

但这并没有提供太多调试信息......并且不会使用错误消息强制执行任何格式化。因此,您可能会产生完全相同的错误,产生两个不同的错误消息...例如“数据库连接失败”与“无法连接到数据库”

当然,如果它冒泡到顶部,它将打印堆栈跟踪,这很有用,但它并不总是告诉我我需要知道的一切,通常我最终不得不开始射击var_dump()发现错误的地方以及在哪里的陈述......虽然这可能会被一个体面的异常处理程序所抵消。

我开始考虑类似下面的代码,其中我需要异常的thrower来提供必要的args以产生正确的错误消息。我想这可能就是这样的方式:

  • 必须提供最低级别的有用信息
  • 产生一些一致的错误消息
  • 一个位置(异常类)中的异常消息模板,因此更容易更新消息...

但我发现缺点是它们更难使用(需要你查找异常定义),因此可能会阻止其他程序员使用提供的异常......

我想对这个想法发表评论,&一致,灵活的异常消息框架的最佳实践。

/**
* @package MyExceptions
* MyWrongTypeException occurs when an object or 
* datastructure is of the incorrect datatype.
* Program defensively!
* @param $objectName string name of object, eg "\$myObject"
* @param $object object object of the wrong type
* @param $expect string expected type of object eg 'integer'
* @param $message any additional human readable info.
* @param $code error code.
* @return Informative exception error message.
* @author secoif
*/
class MyWrongTypeException extends RuntimeException {
    public function __construct($objectName, $object, $expected, $message = '', $code = 0) {
        $receivedType = gettype($object) 
        $message = "Wrong Type: $objectName. Expected $expected, received $receivedType";
        debug_dump($message, $object);
        return parent::__construct($message, $code);
    }
}

...

/**
 * If we are in debug mode, append the var_dump of $object to $message
 */
function debug_dump(&$message, &$object) {
     if (App::get_mode() == 'debug') {
         ob_start();
         var_dump($object);
         $message = $message . "Debug Info: " . ob_get_clean();
    }
}

然后使用:

// Hypothetical, supposed to return an array of user objects
$users = get_users(); // but instead returns the string 'bad'
// Ideally the $users model object would provide a validate() but for the sake
// of the example
if (is_array($users)) {
  throw new MyWrongTypeException('$users', $users, 'array')
  // returns 
  //"Wrong Type: $users. Expected array, received string
}

我们可能会在自定义异常处理程序中执行类似nl2br的操作,以使html输出更好。

正在阅读: http://msdn.microsoft.com/en-us/library/cc511859.aspx#

并没有提到这样的事情,所以也许这是一个坏主意......

5 个答案:

答案 0 :(得分:34)

我强烈推荐Krzysztof's blog的建议,并注意到你的情况似乎是在试图处理他所谓的使用错误。

在这种情况下,所需要的不是指示它的新类型,而是关于导致它的更好的错误消息。作为这样的辅助函数:

  1. 生成要放入异常的文本字符串
  2. 生成整个例外和消息
  3. 是否需要。

    方法1更清晰,但可能会导致更冗长的使用,2则相反,交易更简洁的语法。

    请注意,这些函数必须非常安全(它们本身永远不会导致不相关的异常),并且不会强制提供在某些合理用途中可选的数据。

    通过使用这些方法中的任何一种,您可以在以后更轻松地将错误消息国际化。

    堆栈跟踪至少为您提供了功能,可能还有行号,因此您应该专注于提供不容易解决的信息。

答案 1 :(得分:19)

我不会减损有关Krzysztof博客的建议,但这是一种创建自定义异常的简单方法。

示例:

<?php
   require_once "CustomException.php";
   class SqlProxyException extends CustomException {}

   throw new SqlProxyException($errorMsg, mysql_errno());     
?>

背后的代码(我借用某处,向任何人道歉)

<?php

interface IException
{
    /* Protected methods inherited from Exception class */
    public function getMessage();                 // Exception message
    public function getCode();                    // User-defined Exception code
    public function getFile();                    // Source filename
    public function getLine();                    // Source line
    public function getTrace();                   // An array of the backtrace()
    public function getTraceAsString();           // Formated string of trace

    /* Overrideable methods inherited from Exception class */
    public function __toString();                 // formated string for display
    public function __construct($message = null, $code = 0);
}

abstract class CustomException extends Exception implements IException
{
    protected $message = 'Unknown exception';     // Exception message
    private   $string;                            // Unknown
    protected $code    = 0;                       // User-defined exception code
    protected $file;                              // Source filename of exception
    protected $line;                              // Source line of exception
    private   $trace;                             // Unknown

    public function __construct($message = null, $code = 0)
    {
        if (!$message) {
            throw new $this('Unknown '. get_class($this));
        }
        parent::__construct($message, $code);
    }

    public function __toString()
    {
        return get_class($this) . " '{$this->message}' in {$this->file}({$this->line})\n"
                                . "{$this->getTraceAsString()}";
    }
}

答案 2 :(得分:11)

请参阅“框架设计指南”合着者Krzysztof Cwalina博客上的How to Design Exception Hierarchies

答案 3 :(得分:3)

永远不要相信用户“做正确的事”,并包含调试信息。如果您需要信息,则需要自己收集信息并将其存储在可访问的位置。

同样如上所述,如果做某事很难(呃),用户就会避免这样做,所以再次,不要依赖他们的善意和他们需要发送的知识。

这种想法暗示了一种收集信息并记录信息的方法,这意味着在某处使用var_dump()。

另外,正如马克·哈里森(Mark Harrison)所说,一个可以轻松地在某处发送错误信息的按钮对你和用户来说都是非常棒的。它使他们很容易报告错误。您(作为收件人)获得了大量重复项,但重复信息优于无信息。

答案 4 :(得分:-1)

无论您添加了多少细节,请确保

  • 可以轻松剪切和粘贴整个内容,或
  • 有一个报告错误的按钮