我一直在研究PSR-7 UriInterface的实现,关于实现何时应该为某些组件抛出InvalidArgumentException的规范有点令人费解。
例如,UriInterface::withPath指定在无效路径下抛出这样的异常,但同样的docblock指出,“用户可以同时提供编码和解码路径字符”,因为“实现确保了正确的编码。”
/**
* ...
*
* Users can provide both encoded and decoded path characters.
* Implementations ensure the correct encoding as outlined in getPath().
*
* @param string $path The path to use with the new instance.
* @return static A new instance with the specified path.
* @throws \InvalidArgumentException for invalid paths.
*/实现负责管理编码,这一点贯穿于规范的其余部分。
由于实现确保了正确的编码,因此,实现的用户似乎可以将任意数量的其他无效字符传递到像withPath这样的函数中,然后对其进行正确编码,而不是触发异常。
我认为唯一值得使用InvalidArgumentException的情况是,如果withPath被传递给一个非字符串(无论值多少,似乎都是口香糖对说明书的解释)。
真正严格地阅读PHP对InvalidArgumentException的简介似乎可以消除这种“严格类型”的解释,但我不禁想知道PHP是否还有其他的想法,特别是考虑到URI语法的一般复杂性。
如果传递了字符串,UriInterface方法(如withPath )是否应该抛出异常?
发布于 2017-09-19 01:21:36
我知道,你的问题有点老:-)
你的假设完全正确!
关于这部分:
用户可以同时提供编码和解码路径字符。实现确保getPath()中概述的正确编码。
这与“无效路径”(在@throws标记中描述)无关。正如你正确地断言的,用户可以同时提供编码和解码的字符,这些字符在correspondingly %的意义上是正确的。一些没有编码的字符将是百分比编码的,而另一些则不是。原则上,编码计划将是:
Percent-encode all URI path characters, except:
- the unreserved characters,
- the reserved characters of the subset "gen-delims",
- the reserved characters of the subset "sub-delims",
- the already percent-encoded characters.另一方面,在以下参数的无效情况下引发异常-- InvalidArgumentException:
withScheme:不是字符串,也不是允许的方案列表的一部分;withHost:不是字符串;withPort:不是数字(还是整数?)并且不在1,65535范围内;withPath:不是字符串;withQuery:不是字符串;withFragment:不是字符串;最后,特殊处理接收作为(可选空)构造函数参数传递的URI字符串($uri):
..。以及URI部件数组,这是对URI字符串参数调用parse_url的结果(此处抛出UnexpectedValueException):
$uriParts = parse_url($uri);
if ($uriParts === FALSE) {
throw new \UnexpectedValueException('URI could not be parsed!');
}注意,我已经列出了UriInterface实现中的所有异常抛出情况。
https://stackoverflow.com/questions/42475770
复制相似问题