返回null或抛出异常一次

Question

我已经找过答案这个问题，我发现了以下建议：

1. 如果你总是希望找到一个值，则抛出如果缺失则为异常。这个例外意味着有问题。如果该值可能丢失或存在，并且两者都对应用程序逻辑有效，则返回null。
2. 只有在发生异常时才会抛出异常。如果预期该对象的行为不存在，则返回null。

但是我应该如何解释他们在我的（这么随便）情况： 我的web应用程序控制器接收请求显示详细信息具有一定的ID的用户。控制器要求服务层获取用户，然后服务返回该对象（如果找到）。如果不是，则发送到“默认”位置的重定向。

如果有人在请求URL中传递了无效的用户标识，该怎么办？我是否应该将其视为“预期的行为”并将null返回给控制器，或者我应该将其称为“问题或意外行为”，从而在服务方法内引发异常并捕获到控制器中？

从技术上来说，毕竟这并不是什么大的差别，但我想按照标准召集的方式来做正确的做法。在此先感谢您的任何建议。

编辑： 我认为，由应用程序生成的URL是有效的和现有的 - 当用户点击时，应该找到具有证书编号的用户。我想知道如何处理这种情况，当用户尝试通过在浏览器的地址栏中手动输入URL来访问具有错误（不存在）用户标识的URL时。

Answer 1

我个人的建议是记录错误的详细信息（IP地址，无效的用户ID），并将用户重定向到一个错误页面，表示发生了一些错误，并且管理员已收到通知。点击so-n-so链接返回到您的主页等。

要点是，无论您是抛出异常还是返回null，只要确保最外层过滤器或处理程序在响应之前“记录”了详细信息返回给用户。

Answer 2

如果我理解正确，包含用户标识的请求来自客户端（不受控制）。应用您引用的经验法则：无效的用户输入是完全可以预期的情况，它不需要例外，而是通过向客户端返回适当的错误消息来优雅地处理空值。

（OTOH如果在请求中的用户ID被自动由另一个应用程序所产生/从DB等，未来的用户ID无效。将意外，从而异常将是适当的。）

Answer 3

What should I do when someone passes invalid user id inside the request URL? 

你必须两种选择：显示您提到的“默认”页面或返回“未找到”/ 404。

关于null，这取决于。如果考虑空不可接受的参考，然后用@NotNull和注释注释应需要时得到一个空参考做正确的事情吧：那是，抛出（未经检查的）异常（当然你需要使用令人惊叹的@NotNull注释才能工作）。

你在链条上的做法取决于你：对于我试图伪造用户ID的人返回404听起来非常接近最佳。