4

我已经在寻找这个问题的答案，并找到了以下建议：

  1. 如果您总是期望找到一个值，那么如果它丢失则抛出异常。异常意味着存在问题。如果该值可能丢失或存在，并且两者都对应用程序逻辑有效，则返回 null。
  2. 只有当它确实是错误时才抛出异常。如果对象的预期行为不存在，则返回 null。

但是在我的（如此随意的）案例中我应该如何解释它们：我的网络应用程序控制器正在接收请求以显示具有特定 ID 的用户的详细信息。控制器要求服务层获取用户，然后服务返回对象，如果找到的话。如果不是，则发出到“默认”位置的重定向。

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

从技术上讲，这毕竟不是很大的区别，但我想按照标准的惯例以正确的方式做到这一点。在此先感谢您的任何建议。

编辑：我假设应用程序生成的 URL 是有效且存在的 - 当用户单击时，应该找到具有特定 ID 的用户。我想知道如何处理一种情况，当用户尝试通过在浏览器的地址栏中手动输入 URL 来使用错误的（不存在的）用户 ID 访问 URL 时。

4

3 回答 3

4

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

（OTOH，如果请求中的用户 ID 是由另一个应用程序自动生成/来自 DB 等，无效的用户 ID 将是意外的，因此例外是适当的。）

于 2011-01-23T13:31:03.550 回答
0 
What should I do when someone passes invalid user id inside the request URL?

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

关于null，这取决于。如果您认为null对引用不可接受，则对其进行注释，@NotNull并且注释将在获取null引用时负责执行正确的操作：即抛出（未经检查的）异常（当然您需要使用惊人的 @ NotNull 注释使其工作）。

你在链条上做什么取决于你：对我来说，向试图伪造用户 ID 的人返回 404 听起来真的很接近最优。

于 2011-01-23T15:56:06.633 回答
0

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

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

于 2011-01-23T13:20:28.560 回答