try/finally without catch

You will get a YSOD, but the finally block executes before the YSOD.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
}
finally
{
int foobar = 1 + 1;
}

This is kind of like a IDisposable patter at the method and code block level. It means, on the way out of this code block, I want some clean up code to run. Off hand I can’t think of a good reason for this if you aren’t releasing resources. Using it as a control of flow technique looks very iffy especially if it wasn’t the error you were expecting.

Identical behavior to the above, YSOD, but finally block runs just before the YSOD. The following is code you’d see in code generation scenarios where the try/catch/block is code generated with the hope that the developer would fill better error handling later.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
}
catch (Exception) {
throw;
}
finally
{
int foobar = 1 + 1;
}

YSOD after line one, no other code after the error is executed

int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
int foobar = 1 + 1;

Commenting Code

It is important to comment your code for maintenance developers benefit.

//instantiate object
Foo fooObject = new Foo();

This is important because, maintenance developers are unlikely to recognize the most common single line code pattern in object oriented development.

//call a method in the class
fooObject.SomeMethod(1,2,3);

This likewise is important because maintenance developers are unlikely to grasp the principle of methods and invocations.

//I’m smart and you’re stupid.

This is important because any maintenance developer that doesn’t grasp object instantiation and method invocation probably will need to be explicitly filled in on your utter lack of respect.

Keep in mind, that according to accurately compiled statistics, 61%* of all code will be debugged and maintained by the original developer.

Unit Test Checklist for .NET business objects

1 test per method
1 assertion per method (unless it is testing something trivial, like null on return object)
Always check for null on return object unless null means something.
Always add ExpectedException test for System.ArguementNullException, unless null means something or if it is an optional parameter. (NullReferenceException just isn’t as useful because you see it so often.)
Repeat tests for each constructor.