考虑以下代码。
class C {}
/**
* @throws \InvalidArgumentException
*/
function classCreateInstance($class) {
if (!is_string($class)) {
throw new \InvalidArgumentException("Class name must be a string.");
}
if (!class_exists($class)) {
throw new \InvalidArgumentException("Class '$class' does not exist.");
}
return new $class();
}
/**
* @return C
*/
function foo() {
return classCreateInstance(C::class);
}
有一个函数可能会抛出异常，因为它不知道有关$class争论。
另一方面，调用代码知道“C”是有效的类名，因此它会假设“InvalidArgumentException”永远不会发生。它希望避免冗长的 try/catch，并且希望避免拥有自己的@throws标签。特别是如果它不“允许”有一个，因为它正在实现一个不注释异常的接口。
但是，从 IDE/自动代码验证的角度来看，忽略此异常并不安全。
那么......从调用代码的角度来看，处理“几乎不可能”的异常的正确方法是什么？
在爪哇。 “已检查”异常类和“未检查”异常类之间存在区别。只有受检查的异常才是接口契约的一部分，而即使接口没有声明它，也允许抛出“未经检查的”异常。
在 Java 中，在“不应该发生”的情况下，人们会抛出未经检查的异常 - 例如“运行时异常”。
在 PHP 中，这都是基于约定的。方法可以抛出任何他们想要的异常。添加一个@throws文档注释中的标签很好，但它不是由语言强制执行的。
但是，可以将 IDE 或可能的其他代码审查工具配置为基于检查异常与非检查异常的 Java 模型来分析代码。
例如。 PhpStorm 可以选择不需要@throwsRuntimeException 和 LogicException 的 doc 标记。因此，这将允许将这些视为“未检查”异常，但随后编写自定义异常类并将它们视为 Java 中的“已检查”异常。
PHP 中的原生异常类：http://php.net/manual/en/spl.exceptions.php#spl.exceptions.tree http://php.net/manual/en/spl.exceptions.php#spl.exceptions.tree并不是说这些都继承自 LogicException 或 RuntimeException，因此它们都将被视为“未检查”。只有根类，Exception（和自定义子类）将被视为“已检查”。
这种区别还意味着，如果您调用没有声明/注释的异常的方法/函数，您仍然需要考虑可能会引发异常。这可以被涵盖，例如通过应用程序顶层的 try/catch 。 （例如index.php）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
