可选的无效查询字符串变量

Question

这是一个有点哲学的问题。我有一个.net（但可能是任何平台）的帮助程序库，它解析查询字符串值。以一个返回Int32的变量为例：我的框架有一个选项，指定该值是必需的还是可选的。如果它是必需的但未提供，则框架会抛出异常。如果它是可选的而未指定，则返回null。

现在基于用户黑客（以一种好的方式）我们的网址出现了一个边缘案例。如果他们使用无效格式化的Int32（“＆amp; ID = abc”）指定变量或提供变量但未指定值（“＆amp; id =”），框架是否应抛出异常或应返回null ？

部分我认为无效变量或格式应返回null。认为即使参数是可选的，无效格式化的查询字符串或值仍然会引发异常可能是有效的。

思想？

Answer 1

我相信如果变量是optionaly，提供变量但不指定值等同于省略变量本身。在这种情况下，返回null似乎没问题。

但是，提供无效格式的值应该导致异常，因为 intent 是提供值。在这种情况下，应该通过某种验证机制通知用户。

Answer 2

404的HttpException（未找到）。您的Web应用程序框架应该知道如何捕获这些错误并重定向到正确的页面。

这实际上是一个未找到的错误，因为ID所指向的资源不存在。

Answer 3

我怀疑你的问题没有“正确”的答案。如果我是使用您的库的开发人员，我希望/希望公共API在其代码注释中包含对URL参数包含错误（错误类型）数据时函数行为的描述。

您也可以制作公共API以充分利用这两个方面：.NET似乎在很多地方采用了“Parse”/“TryParse”方法。如果我是调用者，并且我希望函数在给定无效数据时抛出，我调用Parse（）。如果我不想扔它，我会调用TryParse（）。在我看来，这也是你的API的一个很好的模式。

Answer 4

因为这是抒情的......

在ID之类的东西上，我同意Shawn认为它是404，特别是如果你在考虑状态方面。没有对象，所以找不到。但是，在所有情况下，ID可能不会直接与资源绑定。

如果该项目是真正可选的，则null为空。但是，在这种情况下，可选应该表示“如果存在，它会使呼叫更具体”，并且应始终存在后备。我没有在ID中看到这一点，除非ID被键入页面的可选部分。

从长远来看，我认为您应该查看页面的业务原因以及每个变量的含义。