重新思考空/空处理场景的设计模式
类似以下的函数
function(customerid){
customer=findcustomerbyId(customerid)-->findcustomer
list<Transactions> accounts=getNewTransactions(customer)-->findtransactions
foreach{if(transaction.isGasTransaction()){send(event)..if()sendevent()}}-->send events
}
现在的问题是，每当我们期望函数返回值时，它应该是null值吗？或者，如果数据库找不到值，则应抛出异常。
抛出null值会迫使您编写代码来处理null值/空列表。如果else阻塞，而你的junit情况也会增加(直接成比例)，则会增加。抛出异常将迫使您使用不同的编程风格，并且您需要一些预期异常的测试用例。
像spring-jdbc模板queryForObject一样，如果数据库中没有值，就会抛出异常。(预期-1，但得到0)
这里的正确方向是什么。更多的例外？或使用Optionsl<>java-8类似于其他null替代方案还是使用null？
我们可以在不同的场景中平衡这些风格：)
因此，对于rest api项目，我认为抛出异常会很好，如果你有全局excpetion处理程序(如控制器建议)的原因，你可以在代码中处理异常，而不必担心方法堆栈会处理null检查/空检查，因为异常在建议级别被捕获并相应地传播。
***这是朝着一个方向思考，而不是讨论哪个是最好的*****
问问自己"当有人试图访问不存在的条目时，我希望发生什么？">
如果您想向用户显示消息，您可以抛出一个已处理的Exception来通知下一级发生了问题，从而允许您在catch块中显示某种错误消息。
如果您不想发生任何事情，请使用null对象，这样线程就不会爆炸。用户不会被告知为什么什么都没有发生，这被认为是一种不良做法。
如果缺少条目使程序无法正常运行，则会使用Runtime异常。NullPointerException没有详细说明。NPE可能是由于忘记初始化变量(在现代语言中通常是在编译时捕获的)，而不是访问不存在的某种数据结构中的元素(在现代语言学中通常会导致NoSuchElementException)，因此最好将NPE封装在另一个异常中，该异常包括有关该问题的更多信息。
如果数据库找不到值，这是灾难还是正常情况？考虑以下两种情况：
public void createUser(String userName){
boolean thisUsernameIsUsed = checkIfUsernameAlreadyExistsSQLRequest(userName);
if(!thisUsernameIsUsed){
//create a new user
}
}
和
public String whoMessedUpTheDatabase(database database){
return database.getLastEditedBySQLRequest();
}
在第一种情况下，数据库中没有用户名是可以的。所以，使用null。在第二种情况下，我们希望得到最后一个编辑人员的姓名，因此null实际上是一个例外。