業務用のアプリケーションなどを作成していれば、当然ユーザーが入力したものに対してエラー検証が必要になります。Web (ASP.NET / JSP) の場合は検証コントロールを利用したり、サーバーサイドで検証ロジックを書いて結果を表示するという実にシンプルな方法で実装することが多いため迷いは生じませんが、Windows アプリケーションの場合は色々な魅せ方 (文化) が存在しているようで戸惑うことが多いです。
最も困るのはフォーカス アウト時に毎回エラー検証を行い、それをメッセージ ボックスで表示するという仕様です。これだと先に入力したい項目へフォーカスを移したい時ににくく、うっとうしく感じるユーザーが多いハズです。これなら完全な COBOLer 思考でエラーは上部または下部のステータス バーなりに表示するという発想の方が良いくらいです。
私の場合はフォーカス アウト時 (というより Validating) にはメッセージ ボックスを出さないようにして、ErrorProvider を使ってエラーであることを視覚的に明示するだけに留めるのが好きです。詳しいエラー内容が知りたければ、ErrorProvider のエラーアイコンにマウスを重ねることでしょう。ユーザーも「慣れ」というものがありますから、汎ミス程度でメッセージ ボックスが表示されるのはうっとうしく思われます。そのレベルの慣れを持ったユーザーは、エラー内容を見ずとも自分が入力した内容を見れば自分のミスに気付きます。
ただ最終チェック時には ErrorProvider が掴んでいるエラーをメッセージ ボックスでサマリ表示します。そうでないと何をして良いのかわからない (ErrorPrivider のエラーアイコンにマウス ポインタを重ねるという発想がないなど) ユーザーがいるかもしれないからです。本当はユーザーごとに設定を切り分けると良いのですが、工場のライン系の製品ですと「標準化」がどうしても妨げになってしまいます。
私の方法の詳細ですが、入力内容の検証は適切なコントロールの Validating イベントで行います。エラーであればそのエラー内容を ErrorProvider にセットするメソッドを呼び出すだけです。最終チェック時には ValidateChiildren メソッドを使います。最終チェック時でエラーがあった場合のサマリ表示ですが、ErrorProvider の GetError メソッドをラップしたメソッドを使っています。面倒なので ErrorProvider 拡張コンポーネントで自動化してフレームワークを作っています。これでエラー検証のロジックは分散されることなくわかりやすい実装ができるようになりました。