php – 在界面文档中使用@throws

前端之家收集整理的这篇文章主要介绍了php – 在界面文档中使用@throws前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在编写一个 PHP库,我有疑问.我在我的界面中有类似于以下内容
<?PHP
/**
 * My interface
 *
 * ...
 */
interface MyInterface
{
    /**
     * This method does foo.
     *
     * @throws \RuntimeException If foo can't be done.
     */
    public function fooAndBar();
}
?>

现在,@throws条目并不完全正确,因为接口实际上并没有做任何事情,而是纯粹用于抽象实现细节.但是,我一直使用它,因为当出现错误时,我的所有接口的实现都抛出异常.

但是另一个开发人员可能会写一个不能失败的实现(因此它不能抛出异常),或者他/她可能想使用另一个异常类.

那么你推荐什么?我应该完全避免@throws在接口声明?

考虑使用接口的代码
public function doSomething(MyInterface $my) { ... }

如果甚至其中一个实现可能会引发异常,那么您需要确保处理异常的可能性.

所以,是的,应该记录在案.

即使只有一个实现抛出异常,异常处理仍然需要到位.当然这并不意味着每个方法都应该有一个@throws被打了.它应该仍然只能在适当的地方使用(希望实现合法需要抛出异常的地方).

作为一个更具体的例子,请考虑以下几点:

interface LogWriter
{

    /**
     * @throws LogWriterException
     */
    public function write($entry);

}


class DbLogWriter
{

    public function __construct(PDO $db)
    {
        //store $db somewhere
    }

    public function write($entry)
    {
        try {
            //store $entry in the database
        } catch (PDOException $e) {
            throw new LogWriterException(...);
        }
    }

}

class NullLogWriter
{
    public function write($entry) { }
}

在写入数据库时​​,可能会尝试降低异常的可能性,但一天结束时,这不是一个异常安全的操作.因此,DbLogWriter :: write应该预期会抛出异常.

现在考虑空作者,只是丢弃条目.绝对没有什么可以在那里出错,因此,不需要例外.

然而,如果你有一些$log,而你所知道的就是它是LogWriter的一个实现.你认为它不会抛出异常,并可能意外地让一个冒泡,或者你认为它会抛出一个LogWriterException?我会保持安全的一面,并假设它可以抛出一个LogWriterException.

如果所有用户都知道$log是一个LogWriter,但只有DbLogWriter被记录为抛出异常,用户可能不会意识到$log-> write(…)可能会引发异常.此外,当FileLogWriter稍后创建时,这意味着将会设置实现可能会抛出的异常的预期(没有人会期望FileLogWriter抛出一个RandomNewException).

猜你在找的PHP相关文章