关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗？**更新这个问题，这样就可以通过编辑这篇文章用事实和引文来回答。
上个月关门了。
改进这个问题
有时，会有一系列函数调用，在中间确定结果，并希望中途停止整个函数链。在这种情况下，下面的方法不好吗？
public ResponseObject composeResponse {
try {
ResponseObject response = new ResponseObject();
processA(response);
processB(response);
processC(response);
processD(response);
.
.
.
return response;
} catch (SomeFlagException e){
return response;
}
}对于每个过程函数，它也类似于
public void processA(ResponseObject response){
minorProcess1(response);
minorProcess2(response);
minorProcess3(response);
.
.
.
}在某些特定条件下，比如minorprocess3（），结果是确定的，其余的进程是不需要的。假设这发生在很多minor进程中。
public void minorProcess3(ResponseObject response){
//some process
if (someFlag){
//want end the process and return the result
throw new SomeFlagException(); //SomeFlagException extends RuntimeException
}
}我的头脑告诉我不，因为这不是一个“例外”，而是一个预期的结果。我听说，只有在无法合理解决的情况下，才应该抛出未经检查的例外。但是我只能想办法让代码变得干净，否则代码必须将条件检查级联到基函数。
编辑：添加我的情况信息。它是一个web项目，因此它应该返回正确的响应和有效负载。有时请求应该由204/40x响应。不需要有效载荷，因此不需要进一步的过程，应该放弃。
2条答案
按热度按时间eblbsuwk1#
您不应该抛出异常作为算法逻辑的一部分。例外情况必须表明我们不希望出现错误
更干净的方法是
process(ResponseObject)以及minorProcess(ResponseObject)方法返回一个boolean值，该值指示响应过程是否应继续。参见示例：
当使用
&&运算符，如果第一个条件为false，则不计算第二个条件。minorprocess示例：
fnx2tebb2#
是的，这样做是很糟糕的做法。
例外意味着某些方法不能履行其契约。你所问的方法恰恰相反：用例外来表示早期成功。
虽然它在技术上是可行的，但它与异常的预期含义大相径庭，因此我不得不强烈建议不要使用这种方法。
我听说，只有在无法合理解决的情况下，才应该抛出未经检查的例外。
嗯，这是个坏建议。作为抛出异常的调用方，如何知道调用堆栈上的某个调用方方法在失败后是否可以继续成功？这只能在调用方的上下文中决定（是否有故障的回退策略），很少取决于异常的类型。这不是你的责任来决定，即使你试图作出这个决定，它很可能是错误的。
e、 g.对于你的来电者来说，如果你失败是因为
NullPointerException或者IOException，仅举两个未检查/检查类别的突出例子。重要的是，你失败了，也许打电话的人知道在你失败后如何继续。