Question

在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;
    }

Answer 1

一般来说，多个return s不一定是反模式。在最坏的情况下，方法中可能有许多退出点，这对于正在阅读代码并且可能使其难以维护的开发人员来说可能会造成混淆......也许但这不是您似乎要求的。

您提供的代码示例对我来说都是反模式。

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

首先，这就是Exception的用途。如果在方法中执行代码时出现问题，请抛出一个Exception，其中包含一个intent intent和一个描述问题的好消息。

代码的第一个版本：

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;
}

似乎返回一个boolean作为退出代码＆＃34;工作＆＃34;或者＆＃34;没有工作＆＃34;。这不是非常有用，因为如果它不起作用，你就不知道为什么。此外，它需要调用代码来检查他们可能忘记做的返回值。

Answer 2

对void方法进行显式返回没有任何问题。但是，如果可能的话，通常的做法是从方法中只返回一个（尽管如果逻辑需要它可以有多个并且你尽可能简单地编写代码 - 没有块 - 这样整体流程没有混淆）。

如果你引用的话，你应该简单地回来吗？这一切都取决于要求。您的客户似乎是将调用此方法的程序员。他们是否认为null参数是方法的逻辑错误，还是认为它是有效的？

如果是前者，那么我建议你使用注释（@NotNull）来确保参数不为null。不幸的是，有几个可供选择，所以你必须找出最适合你的架构。

如果你真的不想使用注释（并且null被认为是错误），那么抛出异常。

返回void方法是一种好习惯吗？

2 个答案: