返回 null 或再次抛出异常
我已经寻找了这个问题的答案，并且找到了以下建议：
- 如果您总是期望找到一个值，那么如果该值丢失，则抛出异常。出现异常就意味着存在问题。如果该值可能缺失或存在，并且两者对于应用程序逻辑都有效，则返回 null。
- 仅当确实是错误时才抛出异常。如果对象的预期行为不存在，则返回 null。
但在我的（如此随意的）案例中我应该如何解释它们： 我的网络应用程序控制器正在接收显示具有特定 ID 的用户详细信息的请求。控制器请求服务层获取用户，然后服务返回对象（如果找到）。如果没有，则会重定向到“默认”位置。
当有人在请求 URL 中传递无效的用户 ID 时，我该怎么办？我应该将其视为“预期行为”并向控制器返回 null，还是应该将其称为“问题或意外行为”，从而在服务方法内抛出异常并在控制器内捕获？
从技术上讲，这毕竟不是一个很大的区别，但我想通过遵循标准惯例以正确的方式做到这一点。预先感谢您的任何建议。
编辑： 我假设应用程序生成的 URL 有效且存在 - 当用户单击时，应该找到具有特定 ID 的用户。我想知道当用户尝试使用错误（不存在）的用户 ID 访问 URL 时，如何通过手动将 URL 键入浏览器的地址栏来处理这种情况。
I've already looked for the answer for this question, and I've found the following suggestions:
- If you are always expecting to find a value then throw the exception if it is missing. The exception would mean that there was a problem. If the value can be missing or present and both are valid for the application logic then return a null.
- Only throw an exception if it is truly an error. If it is expected behavior for the object to not exist, return the null.
But how should I interpret them in my (so casual) case:
My web app controller is receiving request to show details for a user with a certain id. Controller asks the service layer to get the user, and then the service returns the object, if it's found. If not, a redirect to 'default' location is issued.
What should I do when someone passes invalid user id inside the request URL? Should I consider it as "expected behaviour" and return null to the controller, or perhaps should I call it a "problem or unexpected behaviour" and thus throw an exception inside the service method and catch in inside the controller?
Technically it's not a big difference after all, but I'd like to do it the right way by following standard convetions. Thanks in advance for any suggestions.
EDIT:
I assume, that the URLs generated by the app are valid and existing - when clicked by user, the user with a certaing id should be found. I want to know how to handle a situation, when user tries to access URL with wrong (not existing) user id, by manually typing the URL into browser's address bar.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我理解正确的话，包含用户 ID 的请求来自客户端（不受您的控制）。应用您引用的经验法则：无效的用户输入是完全可以预期的情况，这不需要异常，而是通过向客户端返回适当的错误消息来优雅地处理空值。
（OTOH，如果请求中的用户 ID 由另一个应用程序自动生成/来自数据库等，则无效的用户 ID 将是意外的，因此例外是适当的。）
If I understand you correctly, the request containing the user ID is coming from a client (out of your control). Applying the rules of thumb you quoted: invalid user input is an entirely expectable case, which would not require an exception, rather handle the null value gracefully by returning an appropriate error message to the client.
(OTOH if the user id in the request were automatically generated by another app / coming from DB etc, an invalid user ID would be unexpected, thus an exception would be appropriate.)
我个人的建议是记录错误详细信息（IP 地址、无效的用户 ID）并将用户重定向到错误页面，该页面显示发生了某些错误并且已通知管理员。单击 so-n-so 链接返回您的主页等。
重点是，无论您抛出异常还是返回 null，只需确保最外面的过滤器或处理程序“记录”之前的详细信息响应返回给用户。
My personal suggestion would be to log the error details (IP address, the invalid user ID) and re-direct the user to an error page which says that some error has occurred and the administrators have been notified. Click on so-n-so link to go back to your home page etc.
Point being, whether you throw exception or return
null, just make sure that the outermost filter or handler "logs" the details before the response is returned to the user.您有两种选择：显示您提到的“默认”页面或返回“未找到”/404。
关于 null，这取决于情况。如果您认为引用不能接受 null，请使用
@NotNull对其进行注释，并且注释应在获得null 引用：也就是说，抛出一个（未经检查的）异常（当然，您需要使用令人惊叹的 @NotNull 注释才能使其工作）。你在链上做什么取决于你：对我来说，向试图伪造用户 ID 的人返回 404 听起来非常接近最佳状态。
You have two choices: show the 'default' page you mentioned or return a "Not found" / 404.
Regarding null, it depends. If you consider null unacceptable for a reference, then annotate it with
@NotNulland the annotation shall take care of doing the correct thing upon getting a null reference: that is, throwing an (unchecked) exception (of course you need to work with the amazing @NotNull annotation for this to work).What your do higher up the chain is up to you: to me returning a 404 to someone trying to fake user IDs sounds really close to optimal.