处理由于引入类型暗示而导致的PHP致命类型错误

TL；DR

• 我们是否可以配置PHP，使其在类型提示导致参数类型错误时不会导致致命错误，而是导致警告
• PhpStorm/GIT是否有插件/扩展阻止保存或推送包含未解决问题的代码（最好只针对类型提示问题进行过滤）

---

对于一个有点时髦的代码库的项目，我正在研究，我们正在尝试在我们可以的地方加入类型暗示。 我们决定这样做是为了使代码库更易于阅读和维护

我来自C#背景，因此显然编译器让我变得懒惰，因为它基本上告诉我何时尝试传递错误类型的值。在PHP中，我们必须依赖IDE来告诉我们，但由于没有编译，它实际上并不阻止我们实现在运行时会导致致命错误的代码路径

由于我们都希望继续使用这些类型提示，而不是让它在运行时导致致命错误，因此我们想知道是否可以配置PHP，使其在类型提示失败时抛出警告而不是致命错误。这将允许代码继续运行，并且仍然通知我们需要修复此问题

我理解类型提示应该会导致设计上的致命错误，但是我们正在尝试暂时解决这个问题

---

对于我们来说，同样有效的（并且可能是理想的）是某种插件，它以某种方式阻止我们保存/推送存在此类未解决问题的代码。我们正在使用PhpStorm和GIT进行版本控制。

我的建议是开始对添加的任何新代码或更改的旧代码实施自动测试。因此，您将立即看到是否破坏了任何内容，或者是否存在触发类型错误的执行路径

---

我不确定这是否可行，我怀疑是的

然而，请不要

相反，你可以：

• 例如，编写单元测试
• 如果传递了值，则在需要类型时允许“null”响应和参数
• 使用代码质量检查器要求代码通过某些条件，例如（还有许多其他的！）

空响应或空参数，考虑以下内容：

/**
 * @var User
 * @ORM\ManyToOne(targetEntity="User\Entity\User", fetch="EAGER")
 * @ORM\JoinColumn(name="bcc_user_id", referencedColumnName="id", nullable=false)
 */
protected $bcc;

这是我的一个项目中一个类的属性的示例。对于本例中的邮件实体。它应该有一个实例用户的类对象。正常（生成的）getter/setter最终将是：

/**
 * @return User
 */
public function getBcc() : User
{
    return $this->bcc;
}

/**
 * @param User $bcc
 *
 * @return Mail
 */
public function setBcc(User $bcc) : Mail
{
    $this->bcc = $bcc;

    return $this;
}

然而，它是电子邮件的“密件抄送”。所以，它可以是空的。或者可以删除一个值，使其为空。因此，我们必须在setter中允许一个

null

作为param。getter必须能够返回

null

/**
 * @return null|User
 */
public function getBcc() : ? User
{
    return $this->bcc;
}

/**
 * @param null|User $bcc
 *
 * @return Mail
 */
public function setBcc( ? User $to) : Mail
{
    $this->bcc = $bcc;

    return $this;
}

完成了。只需要两个问号

---

另外，请看一下和发行说明。

您是否考虑过添加自动单元测试，以便在开发过程中捕获这些致命错误？@EriksKlotins是的，实际上很多，但是我正在处理的代码库非常大，很遗憾，开始添加测试并不是一件小事。如果是这样的话。感觉上你真的想设置一个，并且PhpStorm有一个内置的“严格类型检查规则违反”检查，它也应该警告你。我想关键点是它的自动化，对吗？@lvaroGonzález我想我们已经在使用它了（我还不太熟悉PHP，所以我可能是错的）。问题是，我需要一个工具来防止代码与主分支合并（严格的类型检查只会发出警告）。我不在乎它在哪个阶段被阻止，在PhpStorm中的某个地方或者Git客户端对我来说似乎是合乎逻辑的。我是自动化测试的支持者，如果可能的话，我很乐意添加测试。我会根据你提供的文章重新考虑。然而，即使我们进行了自动化测试，也不能保证没有由于添加类型提示而导致的类型错误，因为人类仍然必须覆盖所有这些情况。假设系统按原样工作，只需要对更改的部分进行测试。当然，仍然需要人类来设计测试用例。但是，您只做了一次，而且再也不会回头看同样的问题，因为在我看来，将参数设置为null似乎有点不对劲，除非它们“可以”为null，如您的示例中所示。我们的问题是，我们的开发人员不小心将null传递给他们应该检查的地方，或者抛出异常或w/e。正如我在另一个回答中所说的，单元测试对我来说似乎很棒，因为没有它们我通常不会工作，但在这个特定的项目中它有点困难。Codacy是我必须关注的东西，如果它阻止我们提交或保存根据Codacy无效的代码，那么这肯定是我想要使用的东西。