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

個人的には、私は気にしません。バリデーターが失敗すると、実際のホッケーが進行中であることを意味します。したがって、double.Parse（）の例外は、おそらくその時点では完全に悪いことではありません。

私はそれらを数千回使用しましたが、問題はありませんでした。 。 。

Answer 2

はバリデータの信頼は安全です。しかし、あなたのコードヒントでTryParseを実行することで間違って行くことはできません。

Answer 3

この場合、バリデータが正しく実行されることを期待しているので、私はtryparseを使用しません。そうすれば、誰かがあなたのバリデーターを変更した場合、tryparseを使用していた場合、静かに失敗する代わりに例外がスローされます。

Answer 4

TryParseを使用します。バリデーターは動作するはずです。私は見ていないし、どこにないのかも分からない。つまり、コードは常に悪い値から自分自身を保護しようとするべきです。コードにはバリデーターが含まれている可能性がありますが、将来的にはそうでないかもしれないので、バリデーションが有効であるという理由だけで、そのコードに依存することはできません。サーバ側でバリデータが起動する前に変数を解析する）。 ParseとTryParseを置き換えるのと同じくらい単純なので、TryParseを使用しないで、検証されていない入力項目の潜在的な問題から身を守る必要はありません。

Jakesコメントに応じて。彼はあなたがエラーを投げて検証がうまくいかないかどうかを知っていますが、その場合はtry catchブロックになければなりません。だから、このインスタンスでは、実際にTryParse文と同じことをしていますが、スローされる可能性のある例外を処理するために余分なコードを記述しなければならず、成功のためにブールをチェックするより遅くなります。

Answer 5

はい、誰かがバリデータを変更/削除した場合、実際に例外がスローされてアプリケーションに問題があることがわかります。初期の失敗は速く失敗する（またはそのようなもの）。また、余分なtry catchブロックを追加する必要はありません。これは例外であり、グローバルエラーハンドラによって捕捉されるはずです。 Webの設定でcustomerErrors code = 500かそのようなものです。