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?

Comments

• Anonymous
  February 16, 2004
  Is the debugger really so simple that it will lock itself up like this?
• Anonymous
  February 16, 2004
  I'm guessing you didn't try it. I'd respond in more depth but I don't want to give it away so soon.
• Anonymous
  February 16, 2004
  It's funny to see C++ coding style persisting even after it's not needed anymore ;-)
  Since m_items = null (common typo) won't compile in C#, why not use the simpler notation?
• Anonymous
  February 16, 2004
  Good habits die hard! I primarily code in C++, so it's a lot easier for me to keep the habit of the variable on the right when comparing to a constant, then to switch back and forth depending on what language I'm using. When C# becomes my primary dev language I'll need to adjust lots of habits to make sure they are still worthwhile. This one is certainly harmless in C#, and is a good habit in C++.
• Anonymous
  February 16, 2004
  I haven't tried it, my VS will only work with unmanaged code. What will happen? The debugger will evaluate the property on a different thread than the one it interrupted so it should be stuck waiting for the lock, shouldn't it?
• Anonymous
  February 16, 2004
  In this specific case the debugger does evalute it on the same thread. It can successfully evalute the property since System.Threading.Monitor allows code executing on the same thread to obtain the lock.
  
• Anonymous
  February 16, 2004
  The comment has been removed
• Anonymous
  February 17, 2004
  The comment has been removed