对于用户定义的函数,传递非法类型的参数会导致 TypeError。 对于内部函数,其行为取决于多种因素,但默认是抛出警告并返回 null。 该 RFC 建议始终为所有无效参数类型生成 TypeError
对于用户定义的函数,传递非法类型的参数会导致 TypeError
。 对于内部函数,其行为取决于多种因素,但默认是抛出警告并返回 null。 该 RFC 建议始终为所有无效参数类型生成 TypeError 异常,无论函数是用户定义的还是扩展定义的。
首先,对当前行为的详细描述是有序的。 对于无效类型的用户函数参数,无论 strict_types 选项如何,总是会导致 TypeError:
function foo(int $bar) {}
foo("not an int");
// TypeError: Argument 1 passed to foo() must be of the type int, string given
上述代码错误情况如下所示
当然,strict_types
改变了哪些值被认为与某种类型兼容,但它不会修改错误报告机制。 对于内部函数,基本的行为是抛出警告并返回 null:
var_dump(strlen(new stdClass));
// Warning: strlen() expects parameter 1 to be string, object given
// NULL
上述代码产生的错误情况如下所示
null 返回值只是大多数函数遵循的约定。 还有大约 150 个函数会返回 false。 但是,如果启用了 strict_types
,则会生成 TypeError,这与用户定义的函数一致:
declare(strict_types=1);
var_dump(strlen(new stdClass));
// TypeError: strlen() expects parameter 1 to be string, object given
上面代码产生的错误如下所示
此外,有些函数会选择始终生成 TypeError,而不管 strict_types
设置如何。 所有构造函数都是这种情况,因为它们没有返回空值的有意义的方式。 其他函数,例如 random_int
或整个 sodium
扩展,也可以选择抛出。 新引入的方法通常会这样做,以便在所有错误条件下始终抛出异常。
最后,报告错误的方式取决于检测到违规的机制。 以上描述适用于内部函数通常使用的 zend_parse_parameters/ZEND_PARSE_PARAMETERS
api。 但是,函数可以另外指定参数信息(通过反射提供)。 如果参数信息指定了类型,那么违反这些将始终导致 TypeError。
这可能导致错误行为取决于哪个参数无效的特殊情况:
var_dump(DateTime::createFromFORMat(new stdClass, "foobar"));
// Warning: DateTime::createFromFormat() expects parameter 1 to be string, object given
// bool(false)
var_dump(DateTime::createFromFormat("foobar", "foobar", new stdClass));
// TypeError: Argument 3 passed to DateTime::createFromFormat() must be an instance of DateTimeZone or null, instance of stdClass given
在前一种情况下,zend_parse_parameters
检测到类型不匹配并导致警告和错误,在后一种情况下,参数信息检测到类型不匹配并导致 TypeError。 都是为了同一个功能。
--结束END--
本文标题: PHP TypeError 内部函数的一致类型错误
本文链接: https://www.lsjlt.com/news/568928.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0