在 try 块中使用 return 是否是良好的编程实践？

Question

我很好奇在try块中是否应该有return语句的最佳实践。

我有一个方法调用了一个返回整数并可能抛出IllegalArgumentException异常的服务方法。有两种方法可以实现：

第一种：

public int getLookupStatus(String lookupType)
{
    try
    {
        return this.lookupService.getCountOfLookupRecords(lookupType);
    }
    catch(IllegalArgumentException ex)
    {
        throw new RestException();
    }
}

第二点：

public int getLookupStatus(String lookupType)
{
    int count;

    try
    {
        count = this.lookupService.getCountOfLookupRecords(lookupType);
    }
    catch(IllegalArgumentException ex)
    {
        throw new RestException();
    }

    return count;
}

在第二种方法中，count变量似乎是不必要的，但对我而言，第一种方法似乎是错误的。是否有任何特定的原因来支持其中一种方法？

- user138439

---

第一个代码更易读，第二个可能无法编译。 - assylias

第二个代码应该能编译通过——“count”依然是被明确赋值的。不过我还是更喜欢第一个代码。 - Jon Skeet

@assylias 第二个应该可以编译，因为 count 是一个原始类型。如果它是像 String 这样的东西，就不行了。 - Vivin Paliath

@VivinPaliath 这与明确的赋值有关，正如Jon所指出的那样，该代码也可以编译为Object或String。 - assylias

@VivinPaliath 为什么会这样呢？无论是对象还是基本类型，该值都在成功完成 count = 行时进行初始化。如果该行未能完成，则编译器知道 throw New RestException() 将会发生，从而阻止了 return count 的执行。 - yshavit

Answer 1

如果抛出了IllegalArgumentException(或任何其他RuntimeException)，您甚至不会从该方法返回任何内容，程序的正常执行流程将由于该异常而改变，因此在try块中返回值没有问题。

第二个示例中的模式用于在catch块中使用/实例化资源需要关闭时，然后在finally子句中正确处理。

- Marcin Pietraszek

Answer 2

我喜欢第一种版本，因为它看起来更易读。此外，如果引发异常，那么也没关系，因为控制将无论如何退出方法。

我使用第二种模式的唯一原因是在返回之前想要对返回值进行某些操作。

另外，你的代码可能会更好，如果你不处理IllegalArgumentException。在调用方法之前应该有一种方法来验证参数。

- Vivin Paliath

Answer 3

这两种方法都会产生相同的结果，在两种情况下，如果没有错误，将返回一个值，否则将抛出异常。

但是个人更喜欢第一种方法，更容易阅读。

- TheEwook

Answer 4

你应该避免在 finally 子句中使用 return。一般来说，两个块都应该声明一个退出。如果在 try 中使用了 return，那么在 catch 中也应该使用它，在你的情况下，第二个 return 被替换为 throw。

我也会选择第一个代码片段，因为它更易读。

- Damian Leszczyński - Vash

Answer 5

这两种方法最终都是一样的。你不能同时在一个方法中抛出异常和返回值。这两个东西永远不会发生在一起。你可以返回某个值或者抛出异常。

在第二种方法中，return count;语句是必须的，否则编译器会抛出错误消息。这是因为，如果你的代码没有遇到任何异常，它必须按照你的方法原型返回值。

这两种方法除了第一种直接返回值，而第二种存储在变量中并返回变量的值，最终结果是一样的。

还有一件事，你没有在方法定义中声明 throws 子句，这表明 RestException() 是一个未经检查的异常。一般来说，抛出未经检查的异常并不是一个好的实践，因为调用方法可能无法处理它。我建议你抛出一个经过检查的异常。

- Ankur Shanbhag

---

关于未经检查的异常，这确实是主观的、与上下文相关的，并且远非共识。 - yshavit