Question

我正在使用ASP.NET CompareValidator控件来进行数据类型检查。我应该相信这些控件足以直接解析它们的值，还是应该使用TryParse？

示例：

<asp:TextBox ID="uxVolume" runat="server" />
<asp:CompareValidator ID="uxVolumeDataTypeValidator" runat="server" 
    ControlToValidate="uxVolume" ErrorMessage="Volume must be a number." 
    Type="Double" Operator="DataTypeCheck" Text="*" Display="Dynamic" />

我应该在Parse：

的代码隐藏页面中找到

var volume = double.Parse(uxVolume.Text);
// do something

或TryParse：

double volume;
if (double.TryParse(uxVolume.Text, out volume))
{
    // do something
}

Answer 1

是的，但是如果有人更改/删除了您的验证器，那么您确实希望抛出异常，以便您知道应用程序存在问题。失败早期失败（或类似的事情）。此外，您不必添加额外的try catch块，因为这应该是一个异常并被您的全局错误处理程序捕获。在web配置中，customerErrors代码= 500或类似的东西。

Answer 2

就个人而言，我不会打扰。如果验证器失败，那意味着真正的事情正在发生，所以在double.Parse（）上异常可能并不是完全不好的。

我已经使用了几千次并没有遇到任何问题。。

Answer 3

在这种情况下，您希望验证器正确运行，因此我不会使用tryparse。这样，如果有人更改了您的验证器，那么将抛出异常，而不是如果您使用了tryparse则默默地失败

Answer 4

根据我的经验，信任验证器是安全的。但是，在代码隐藏中执行TryParse不会出错。

Answer 5

我会使用TryParse。验证器应该工作。我没见过，也没有看到它的实例。话虽这么说，你的代码应该总是试图保护自己免受坏的价值。代码现在可能有验证器，但将来可能不会，所以你不能依赖它，只是因为验证器应该工作，并不意味着它总是会（你可能会意外地移动代码）在验证器在服务器端触发之前解析变量）。就像用TryParse替换Parse一样简单，没有理由不使用TryParse并保护自己免受未经验证的输入项的潜在问题。

回应杰克斯评论。他写道你知道如果通过抛出错误验证不起作用，那么它必须在try catch块中。所以在这个实例中你实际上和TryParse语句做的事情不同，除了你必须编写额外的代码来处理抛出的潜在异常，抛出异常比检查bool成功要慢。

我应该信任ASP.NET DataTypeCheck验证吗？

5 个答案: