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

StackOverflow https://stackoverflow.com/questions/628408

  •  06-07-2019
  •  | 
  •  

题

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

我看到很多人都在做他们的例外，比如：

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

或者使用自定义异常扩展默认异常，这些异常不会做太多事情，但会更改异常的名称：

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

但这并没有提供太多调试信息......并且不会对错误消息强制执行任何类型的格式。所以你最终可能会得到完全相同的错误，产生两条不同的错误消息......例如“数据库连接失败”与“无法连接到数据库”

当然，如果它冒泡到顶部，它会打印堆栈跟踪，这很有用，但它并不总是告诉我需要知道的一切，通常我最终不得不开始启动 var_dump() 语句来发现出了什么问题以及哪里...尽管这可以通过一个像样的异常处理程序在一定程度上抵消。

我开始考虑类似下面的代码，我在其中 要求 异常的抛出者提供必要的参数来生成正确的错误消息。我想这可能是要走的路：

  • 必须提供最低水平的有用信息
  • 产生有些一致的错误消息
  • 异常消息的模板全部位于一个位置（异常类），因此更容易更新消息...

但我认为缺点是它们更难使用（需要您查找异常定义），因此可能会阻止其他程序员使用提供的异常......

我想对这个想法以及一致、灵活的异常消息框架的最佳实践进行一些评论。

/**
* @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#

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

有帮助吗？

解决方案

我强烈推荐以下建议 克日什托夫的博客 并会注意到，在您的情况下，您似乎正在尝试处理他所谓的“使用错误”。

在这种情况下，需要的不是一个新的类型来指示它，而是一个关于导致它的原因的更好的错误消息。作为这样的辅助函数：

  1. 生成要放入异常中的文本字符串
  2. 生成整个异常和消息

是所需要的。

方法 1 更清晰，但可能会导致使用更加冗长，方法 2 则相反，用更简洁的语法换取不太清晰的结果。

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

通过使用这两种方法中的任何一种，您可以在以后根据需要更轻松地将错误消息国际化。

堆栈跟踪至少为您提供了函数，可能还提供了行号，因此您应该专注于提供不容易从中计算出来的信息。

其他提示

我不会偏离有关 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()}";
    }
}

看 如何设计异常层次结构 《框架设计指南》的合著者 Krzysztof Cwalina 的博客上。

永远不要相信用户会“做正确的事”，并包含用于调试的信息。如果您需要信息，您需要自己收集并将其存储在可以访问的地方。

另外如上所述，如果某件事很难（呃）做，用户会避免这样做，所以再次强调，不要依赖他们的善意和他们对需要发送的内容的了解。

这种想法意味着您收集信息并记录它的方法，这意味着在某处使用 var_dump() 。

此外，正如马克·哈里森所说，一个可以轻松地在某处发送错误消息的按钮对于您和用户来说都非常棒。这使他们可以轻松报告错误。您（作为接收者）会收到很多重复信息，但重复信息总比没有信息好。

无论您添加多少细节，请确保或者

  • 使剪切和粘贴整个内容变得容易，或者
  • 有一个按钮可以为他们报告错误
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top