您是否遇到过一个错误，使用了标准的代码，当您发现问题时，您无法说出它是业务逻辑还是只是某种类型检查以避免空指针异常？ 这些错误对我来说是最糟糕的，他们花了我更多的时间才弄清楚为什么它在那里然后才真正解决了问题。 这是我想更经常发生在我身上的事情，所以让我们谈谈这件事并一起抱怨吧。
免责声明：这个讨论比本文要大，甚至有些人喜欢这种空模式！ ️️ 有时我认为问题在于您实际上不介意null检查，也不会将其视为一个问题，您知道，它只是null检查！ 这有什么错呢？ 这就是这种模式可能是柏忌的时候。
对我来说，如果您的软件抛出空指针，那将是一件好事！ 您的工作是防止这种情况发生，而不是检查每一个数据位是否为空。 它不是狩猎女巫！ 它们在那里爆炸，并给您一些有关潜在错误的反馈，请记住：失败很快！ 我们将在另一篇文章中对此进行探讨。
我有一个案例可以发现这个问题：我正在研究新闻应用程序，并且存在一种业务逻辑，即如果前端发送发布日期，则应将此新闻发布给用户，否则该新闻是草稿，甚至更多，软件应将此日期从字符串转换为时间戳。
到目前为止，看起来似乎很简单，而且后端代码是这样的：
因此，我们有一种将字符串转换为时间戳的方法，它实际上是在进行业务逻辑！ 不仅此空检查没有适当的位置来创建带有其方法的单元，而且他还在辅助方法上隐藏了实现。
一无所获
假设您正在一家面包店的蛋糕生产线工作。 您的工作是得到蛋糕形状，添加面粉并归还； 如果前任员工不给力，您会在面粉上加一点面粉而什么也不会退回吗？ 您可能会抱怨！ 虽然这是一个副作用 。
通过不返回任何内容，您将不承担代码责任，并将问题传递给系统的其余部分，这是一个很难解决的问题，我将告诉您，一个简单的nullScheißa造成的整个周末的痛苦
在巴西炎热的夏天，这是一个阳光明媚的周末，空调在最大程度上发挥作用，我在那里，试图与客户进行质量检查来部署一个项目。 一切正常，直到他们发现一个神秘的错误。 在新的软件过程中，某些日期已另存为null。 我是公司中唯一的开发人员，一个有40多名开发人员的项目，以前对系统的这一特定部分一无所知。 2小时的调试之后，我得到一小段代码： if(date == null) return null; 检查gitlog ，这是从前端解决某些问题的“错误修正”。 我花了一个多小时才了解为什么null可以解决我们凶猛的角度应用问题。 一个甜蜜的一天的代码工作时间和3行更改，删除了一个空代码并解决了该错误。
所以我该怎么做？ 如何在没有null及其“帮助”能力的情况下生活？ 好吧，让它吹！ 混乱为我们指明方向，向我们展示问题以及在哪里采取行动！ 如果您的代码永不失败，您怎么知道它正在工作？
From: https://hackernoon.com/the-null-pattern-haunted-house-54b5ae6e646