Debugging Issues with Inline Property Declarations
VS provides a debugging challenge when it comes to inline property declarations as such as this:
DataRow row = table.Rows[0];
var obj = new SomeClass
{
ID = GetValue<int>(row, "ID"),
Name = GetValue<string>(row, "Name"),
Address = GetValue<string>(row, "Address"),
IsActive = GetValue<bool>(row, "IsActive"),
LastUpdated = GetValue<DateTime?>(row, "LastUpdated")
};
Imagine this scenario: the data row values get passed from the table's row to a class. The GetValue generic method is a helper method that examines the row's value, check for null, and converts any actual values to the correct type. Let's assume that an exception gets thrown when accessing the LastUpdated value from the DataRow. When VS debugs this, the cursor points to the entire definition, and an exception gets thrown without identifying the actual value in error. So when debugging this, it's harder to figure out the erroring field (though not impossible) in this setup.
It's much easier to debug in this setup:
var obj = new SomeClass();
obj.ID = GetValue<int>(row, "ID");
obj.Name = GetValue<string>(row, "Name");
obj.Address = GetValue<string>(row, "Address");
obj.IsActive = GetValue<bool>(row, "IsActive");
obj.LastUpdated = GetValue<DateTime?>(row, "LastUpdated");
The debugger clearly identifies that the LastUpdated assignment is in error. So debugging using this approach in VS is easier, but the two differences aren't as impossible.
When you deploy, it's going to be harder to figure out the erroring field, unless GetValue catches the casting error and passes the name of the field to the exception message. Deploying to production would make it much harder too. Also, if GetValue is a method outside your current assembly (third party or other), you may not be able to debug into it. If the error message is as vague as some of the messages in the .NET framework, then it's going to be more difficult to figure out.