在代码审核中，另一个开发人员和我对处理多个返回的正确或正确方法的辩论很小，如果将指针分配给NULL，然后设置它会产生任何差异与简单返回值相比，后来返回的null。
private ServiceParam getRequestServiceParam(SlingHttpServletRequest request) {
ServiceParam sp = null;
try {
sp = new ServiceParam(IOUtils.toString(request.getReader()));
} catch (IOException e) {
LOGGER.error("IOException", e);
}
return sp;
}
vs
private ServiceParam getRequestServiceParam(SlingHttpServletRequest request) {
try {
return new ServiceParam(IOUtils.toString(request.getReader()));
} catch (IOException e) {
LOGGER.error("IOException", e);
}
return null;
}
在功能上它们看起来相同，但是我们不知道我的一个比另一个更正确。尽管我担心这可能只是一个标签与空格参数。
是否可以从方法返回是否可以是意见问题。但是这里有权衡的话可以谈论某些解决方案比其他解决方案更好。Sonarqube投诉是一个不错的起点，但是有更大的问题。
有些人认为拥有多个回报是不好的，他们想遵守结构化的编程规则。结构化编程比使用goto更好，并且确实会产生一致的代码。
其他人指出，执行一个返回使控制语句嵌套更深，导致代码很难阅读。在第一个示例的情况下，我发现自己在方法中上下扫描，以寻找本地变量获得分配的值的位置，我认为这很烦人。
（Sonarqube在您有多个返回时不会正确计算环境复杂性，顺便说一句。我们很难弄清楚）
也没有任何绩效含义。这只是一个尴尬的编码和不理想的例外处理问题。当您返回null时，您会为调用代码无法检查NULL的引用，从而创建一个机会，最好让异常被抛弃。
我不会为此使用可选的方法，除非看起来像我在monadic上下文中使用的东西，在这种情况下，我将东西链在一起并使用Flatmap来处理我的可选空箱。否则，必须包装和解开此包装是令人讨厌的，它比返回Null好一点，仅仅是因为它迫使通话代码考虑空案例。
在这种情况下，实际的尴尬是由httprequest的阅读引起的，这是引发ioexception的原因。您可以将throws IOException添加到该方法中，并让异常。但是，最好将代码移至任何servlet或Web控制器正在获取httprequest，并以与Servlet或Controller所能处理的任何其他方式进行处理，从而获得HTTPREQUEST，并获得任何IOException。
移动该请求阅读代码后，根本没有这种方法存在的令人信服的理由。删除不必要的代码是一件好事。
我会遵循@khelwood的建议。如果您不想处理函数调用以外的凸起的异常，请使用Optional，如@controlaltdel所示
private Optional<ServiceParam> getRequestServiceParam(SlingHttpServletRequest request) {
try {
return Optional.of(new ServiceParam(IOUtils.toString(request.getReader())));
} catch (IOException e) {
LOGGER.error("IOException", e);
return Optional.empty();
}
}
如果您必须使用null，我更喜欢第二种方法
private ServiceParam getRequestServiceParam(SlingHttpServletRequest request) {
try {
return new ServiceParam(IOUtils.toString(request.getReader()));
} catch (IOException e) {
LOGGER.error("IOException", e);
return null;
}
}
因为我不必三思而后行。因此，没有不必要的变量声明，无需记住其中的内容。（对于可选方法，此参数也是如此。）
更新1 ：对于两个方法，也许是单个方法中的三个返回语句，如果有几个返回语句，则必须考虑其他解决方案。
更新2 ：还有一个声纳规则鱿鱼：S1142
imho
在代码维护方面，多个返回容易出错。多个回报并不是最容易阅读的。
当涉及到这样的选择时，我总是选择不写它的人更容易阅读的代码。
当其他人从现在开始阅读一年后，他们可能会很着急，在某些紧急情况下工作，他们想要一眼就能完全理解的代码。
我努力编写非常易于阅读的代码，即对其他人进行重构的风险较小。
避免在任何可能的地方避免本地变量，以提高性能总是一件好事。如果您太关心可读性，请选择选项1，否则请使用选项2。请查看此答案，以获取有关在返回之前将结果分配给本地变量的详细信息。