Proactive vs Reactive tools: Evaluating Properties
Proactive vs Reactive tools: Prop Eval
One core principle for a debugger is that it should affect your program as little as possible. The reason is pretty straightforward. If your program runs differently under the debugger, the problem you are trying to solve might not reproduce. This is the underlying reason why all debugger devs say FuncEval is Evil. There are, however, a host of useful features that are in direct conflict with this principle. Automatically evaluating properties is one such feature. A property is really a pair of methods in your program. It’s not a good idea for a property read to have a side effect. However the no-side effect rule usually pertains to the abstract state of your object. Take this for example:
using System;
class MyBag
{
System.Collections.Hashtable m_items;
public System.Collections.Hashtable MyItems
{
get
{
lock(this)
{
if (null == m_items)
{
m_items = new System.Collections.Hashtable();
}
}
return m_items;
}
}
static void Main(string[] args)
{
MyBag c = new MyBag();
}
}
This is arguably a reasonable use for a property. The abstract state of c.MyItems is an empty list, in both the case where m_item is null and where m_item is an empty list. The real state however obviously changes if you read the property.
?c
{MyBag}
m_items: null
MyItems: Count = 0
?c
{MyBag}
m_items: Count = 0
MyItems: Count = 0
Typically it is the real state that you care about when debugging, not the abstract one. Should the debugger be evaluating that property? You can turn off automatic property evaluation in the VS debugger (look under tools/options/debugging/General for “allow property evaluation in variables windows”).
If you are stopped at if (null == m_items) line above and FuncEval the property what happens? Why?
