Overlapping Validation Groups and Duplication of Validators

I was solving the following problem: There are two buttons (B1 and B2) on a form and two fields (F1 and F2). B1 should trigger the validation of F1, while B2 makes both F1 and F2 validated.

The concept of validation groups as introduced in .NET 2.0 is well prepared for two logically independent forms of one page, but is quite not ready for above described situations (that are not so rare I think).

I rejected the idea of triggering the validation manually on button click. I wanted to follow the common pattern of validation as much as possible. I'm afraid you cannot share validators among several validation groups nor you can attach several validation groups to a single button. (The latter would be much preferred.) I introduced two validation groups, and there is a duplication of validators for F1 in order to make them included in both validation groups. This duplication is pretty systematic (only ValidationGroup property varies) and recognisable at first sight, but still it is a pitty to have it there.

The Effectiveness of Test-first Approach to Programming

National Research Council of Canada published a paper titled "The Effectiveness of Test-first Approach to Programming", in which the test-first approach leads to higher productivity. Read more comments on the paper on InfoQ. The co-author offers that quality is also better when using test-first approach, although his research showed more consistent quality results only.

Unexpected exceptions in .NET

You can throw any exception you like from any place of your code in C#. That is quite OK. The problem is that the caller may receive any type of exception. One cannot be sure with .NET framework either. Although there is MSDN documentation on what exceptions can be thrown from what methods, you may receive unexpected expections. For example XmlDocument.Load promises to throw XmlException on parsing error, but if you use validating XmlReader, the XmlSchemaValidationException can be thrown.

I like Java throws clause. You just discover all possible types of exceptions by compiling. With that knowledge, you may handle them or explicitly mark them to be passed to your callers. Thus you won't be surprised in run time (possibly on production system).