问题标签 [spl]

PHP为无效键定义了两个SPL例外：

OutOfRangeException: 请求非法索引时抛出异常。这表示应在编译时检测到的错误。

OutOfBoundsException：如果值不是有效的键，则抛出异常。这表示在编译时无法检测到的错误。

由于 PHP 不是一种编译语言，编译时和运行时之间的区别似乎很奇怪，因此我发现很难理解何时使用哪个异常。

目前我的理解是应该抛出...
...OutOfRangeException如果键从根本上和固有地格式错误，例如，如果数组作为键传递。
...OutOfBoundsException如果密钥通常没问题，但不在某些边界内，例如如果100通过但是50最大密钥。

这种理解正确吗？

拥有多个的好处是什么spl_autoload_register

例子：

与：

使用一个

spl_autoload_register('autoload');或者__autoload();

然后在函数内部做逻辑。

快一个；我怀疑这是可能的，但是有没有办法利用array($key => $value);PHP 的语法来处理SplObjectStorage对象？

我的意思是，有没有这样的方法可以实现：

在初始化对象存储的上下文中？截至目前，我只是在使用：（并且可能会继续，考虑到这种可能性的绝对可能性）

会很好，高度怀疑它，但也许有人知道得更好。

我在 Doctrine 模型上创建了一个方法来将相关对象添加到集合中，但是我想在将重复对象添加到该集合时抛出异常。

这是测试：

起初，我认为OverflowException在这种情况下抛出 an 可能是合适的，但我不确定“这个值已经存在”是否与“这个容器已满”相同：

将元素添加到完整容器中时引发异常。

有UnexpectedValueException，但这似乎更适用于类型不正确的变量：

如果一个值与一组值不匹配，则会引发异常。通常，当一个函数调用另一个函数并期望返回值是某种类型或值时，会发生这种情况，不包括算术或缓冲区相关的错误。

我总是可以使用LogicException，但这对于这个用例来说似乎有点通用：

表示程序逻辑错误的异常。这种异常应该直接导致代码中的修复。

这里有更好的选择吗？我的观察正确吗？尝试将重复项添加到必须包含唯一值的集合时，最合适的 SPL 异常是什么？

如何找到文件中的行数SplFileObject？

使用：

有人可以解释为什么会有这样的速度差异：

$maxHeap作为一个对象class MaxHeap extends SplMaxHeap

该spl_autoload_register()函数可以与 3 种类型的回调一起使用：函数、静态方法和常规方法。与其他类型相比，这三种类型有什么优点/缺点吗？

到目前为止，我已经使用了程序化的独立自动加载器函数，并将它们注册到spl_autoload_register()以自动加载我的（通常）命名空间类。不过，最近，我注意到有人提到将自动加载器类与一些著名的 PHP 框架结合使用。

这些天，我几乎所有的代码都是面向对象的，但我并没有真正看到在这个实例中使用“Autoloader”类而不是基本函数的优势。在可测试性方面，我觉得在我的测​​试中使用class_exists()检查来验证程序函数是否正确加载文件感觉很好。

所以我的问题是三个：

1. 哪些优点或特性（如果有的话）可能会促使我重构事物并开始使用完整的对象来自动加载类文件？
2. 除了明显的 OOP 功能之外，我是否遗漏了一些明显的优势？
3. 您能否为程序自动加载器或类自动加载器提供一个案例？

更新

下面是我可能使用的典型自动加载功能的一些示例代码。这是元代码，所以不要寻找错别字。我组织我的目录结构，以便它们反映命名空间。理论上，假设explode_namespaces()函数可以作为静态方法与autoload()类中的静态方法一起包含，所以这是一个好处。将这些不同的“实用程序”函数组合为单个类中的方法可能会更简洁。

我正在编写代码来管理一组独特的对象。这段代码的第一个原型使用了一个关联数组，基本上我一直都是这样做的。

但是，我也热衷于利用添加到更现代 PHP 版本中的功能，例如[SplObjectStorage][1]这样做，部分是作为一种学习经验，部分是因为它一定会提供优势（我见过的基准表明SplObjectStorage可以在很多情况下比数组快）。

当前的实现有一个关联数组，我in_array()在向它添加新对象之前检查对象是否已经在数组中。

我可以看到的一个大问题SplObjectStorage是它似乎（乍一看）不支持键/值关联数组行为，并且只能被视为索引数组。但是，PHP 新功能的文档不符合该语言更成熟部分的文档标准，我可能只是遗漏了一些东西。

我可以SplObjectStorage代替关联数组使用吗？如果是这样，添加新对象时如何定义键？SplObjectStorage更重要的是，与关联数组相比，它们的相对优势和劣势是什么？

I have a Logger interface that accepts a SplFileObject in the constructor to use as the file for that particular log. There is also a log($timestamp, $message) method available to actually do the logging. In my first implementation when instantiating a new object and passing a read-only SplFileObject an exception should be thrown. I wrote up an appropriate unit test:

Normally I would have a method producing the directory name but when I started encountering problems I changed it to an absolute path to rule out that as the cause.

And here's the implementation:

The problem is that the test passes and I can tell by the code coverage generated by the test that isWritable() returns true and SplFileObject::fwrite() on a readonly object returns a non-null value as well.

The really, really weird part of this is that the very same code ran in a non-unit test example fails, just as it should.

Running this from index.php results in xdebug showing an uncaught InvalidArgumentException from FileLogger with the expected message that the file passed is not writable. This is completely baffling, the same exact code is being ran in both situations, yet the code inside the unit test is "failing" and the non-unit tested code is performing as expected.

1. Yes, the file exists. SplFileObject would throw an exception if it didn't.
2. The very exact same code is being ran in both situations, other code that is being ran includes setting up 2 constants, a file directory and a shortcut to DIRECTORY_SEPARATOR, and setting up class autoloading. But, again, this is happening exactly the same in both situations and would result in a failure long before this unit test is actually ran.
3. Help!

Looking at it now the problem seems relatively simple. PHP is running under the _www user and phpunit is running as the user that installed it. These users have different permissions, which makes perfect sense. If you somehow are encountering this problem I suggest you look at edorian's answer and re-evaluate how you are writing your unit tests.