Refactoring 返回void方法是否是一种好的做法？

在void方法中使用return语句来打破这里的逻辑。问题是，当我们这样做时，方法的使用者不知道方法中的逻辑是否完全运行。然而，我的架构师和团队不同意这一点。原因是在这种情况下，当前的消费者并不关心结果

我认为这是反模式编码。这就像吃了一个例外，却没有冒出气泡。大家对此有什么看法

现行守则：

Private void XXX(final String parameter) {
        try {
            if (parameter==null){
                return;
            }
            ....
    }

我的版本

Private boolean XXX(final String parameter) {
        try {
            if (parameter==null){
                return false;
            }
            ....
    return true;
    }

---

一般来说，拥有多重回报并不一定是一种反模式。在最坏的情况下，方法中可能有许多退出点，这可能会让正在阅读代码的开发人员感到困惑，并且可能会使维护变得更加困难……也许这并不是您想要的

在我看来，您提供的代码示例都是反模式的

问题是，当我们这样做时，方法的使用者不知道方法中的逻辑是否完全运行

首先，这就是例外的原因。如果在方法中执行代码时出现问题，则抛出一个异常，该异常包含意图显示类型和描述问题的良好消息

代码的第一个版本：

Private void XXX(final String parameter) {
    try {
        if (parameter==null){
            return;
        }
        ....
}

似乎返回，而不是抛出带有无效参数的异常

代码的第二个版本：

Private boolean XXX(final String parameter) {
    try {
        if (parameter==null){
            return false;
        }
        ....
return true;
}

---

似乎返回一个布尔值作为已工作或未工作的退出代码。这不是很有帮助，因为如果它不起作用，你不知道为什么。它还需要调用代码检查返回值，而他们可能会忘记检查返回值。

为void方法显式返回没有什么错。然而，如果可能的话，一个方法只返回一次是一种很好的常规做法，尽管您可以有多个if逻辑要求它，并且您编写代码时尽可能简单，没有任何块，这样整个流程就不会混淆

你是否应该在你引用的案例中简单地返回？这完全取决于需求。您的客户似乎是调用此方法的程序员。他们认为NULL参数是该方法的逻辑错误，还是认为它是有效的？

如果是前者，那么我建议您使用注释@NotNull来确保参数不为null。不幸的是，其中有几个可供选择，因此您必须找出最适合您的体系结构的

---

如果您真的不想使用注释，并且null被视为错误，则抛出异常。

封装是指客户不知道运行了哪个逻辑。怎么了？