Стоит ли доверять проверке ASP.NET DataTypeCheck?

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" />

в коде за страницей, я должен разобрать:

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

или TryParse:

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

Answer 1

Да, но если кто-то изменяет / удаляет ваш валидатор, то вы действительно хотите, чтобы было сгенерировано исключение, чтобы вы знали, что есть проблема с приложением. Сбой рано, сбои быстро (или что-то подобное). Также вам не нужно добавлять дополнительный блок try catch, потому что это должно быть исключением и быть перехвачено вашим глобальным обработчиком ошибок. В веб-конфигурации customerErrors code = 500 или что-то в этом роде.

Answer 2

Лично я бы не стал беспокоиться. Если валидатор терпит неудачу, это означает, что происходит настоящий обман, поэтому исключение в double.Parse (), вероятно, не совсем плох в этот момент.

Я использовал их несколько тысяч раз и у меня не было проблем. , .

Answer 3

В этом случае вы ожидаете, что валидатор будет работать правильно, поэтому я бы не использовал tryparse. Таким образом, если кто-то изменит ваш валидатор, будет выдано исключение, а не молча, если вы использовали tryparse

Answer 4

Я бы использовал TryParse. Валидатор должен работать. Я не видел, и случай, когда это не так. При этом ваш код всегда должен пытаться защитить себя от плохих значений. В коде теперь может быть валидатор, но в будущем он может отсутствовать, поэтому вы не можете полагаться на то, что он там есть, и только потому, что валидатор должен работать, не означает, что он будет всегда (вы могли случайно переместить код проанализировать переменную до запуска валидатора на стороне сервера). Так же просто, как заменить Parse на TryParse, нет причин не использовать TryParse и защитить себя от потенциальной проблемы с непроверенным элементом ввода.

В ответ на комментарий Джейкса. Он напишет, что вы узнаете, если проверка не сработает, выдав ошибку, и в этом случае она должна быть в блоке try catch. Таким образом, в этом случае вы действительно делаете то же самое, что и оператор TryParse, за исключением того, что вам нужно написать дополнительный код для обработки возможного создаваемого исключения, а генерирование исключений происходит медленнее, чем проверка bool на успех.

Answer 5

По моему опыту, доверять валидатору безопасно. Тем не менее, вы не ошибетесь, выполнив TryParse в своем коде.