Freigeben über

Suggestions for future CDPs?

  • Artikel

In my next blog entry, I'll explain the 11th and final Customer Debug Probe (CDP) that exists in the v1.1 product.  But for the next version of the product (code-named Whidbey), we're looking at adding additional probes, and not just in the area of Interop.  The goal is to help you find, prevent, and/or diagnose bugs in your managed code by allowing you to opt-in to extra run-time checks done by the CLR.  These extra checks slow down the applications that are probed, which is why you should never have these probes enabled in a production environment (unless you're debugging).

Take yesterday's BinarySearch example.  Although many folks figured out the problem quickly, I would categorize that method as error-prone.  Of course, its behavior was consciously chosen for performance reasons.  Why should it force a sort of the array since the careful developer who read the documentation ensured that it is already sorted appropriately?  You're supposed to pass an appropriate comparer (as Ken suggested) or call Array.Sort first (as Chris suggested) or just guarantee that the array is always sorted in increasing order as elements are added.  But since failing to follow the rules doesn't slap you on the wrist - it simply gives a wrong answer some of the time - this seems like a potential candidate for a new CDP.

Imagine a "Binary Search on Improperly Sorted Collection" probe that raises a red flag whenever someone calls Array.BinarySearch or ArrayList.BinarySearch on an unsorted (or improperly sorted) array or ArrayList.  Wouldn't it be nice to have this extra bit of assurance that you aren't going to ship your software with such a bug?  As long as whomever responsible for QA sufficiently exercises the software with the probes turned on, you would get instant notification of the problem.

But certainly there are more compelling probes that could be added.  Any suggestions?  What subtle issues have you run into when writing managed code?  What hypothetical probes would have saved you hours or days of debugging time?  Of course, I can't promise that anything would make it into a future version of the CLR, but your feedback is valuable.  We want to make software development enjoyable and less prone to bugs, even if you don't read the documentation!

Comments

  • Anonymous
    August 26, 2003
    One thing that I would find useful would be to know if a disposable object has been disposed via its finaliser rather than explicitly in code. This normally only happens as a result of an oversight in the code, i.e. Dispose is never called or the code isn't robust to exception conditions, and it's something that often goes unnoticed. C# lessons the burden somewhat with the using statement, but its common to see VB code (even on MSDN) as follows:Dim d As New DisposableObject()d.DoSomething()d.DoSomethingElse()d.Dispose()It should be:Dim d As New DisposableObject()Try d.DoSomething() d.DoSomethingElse()FinallyIf Not d Is Nothing Then d.Dispose()End Try
  • Anonymous
    August 27, 2003
    How about a "Windows Forms Control used from wrong thread" probe? This one catches people out all the time.
  • Anonymous
    August 29, 2003
    Those are both very interesting suggestions. Unfortunately for the second one, it's likely that the probes will continue to be restricted to "core CLR" things, i.e. code in mscorwks.dll or mscorlib.dll. But if nothing else, perhaps a separate diagnostic could be added for such a thing. I believe the Windows Forms folks are already looking into that.Any other suggestions out there?
  • Anonymous
    September 01, 2003
    The comment has been removed
  • Anonymous
    September 08, 2003
    Thnax
  • Anonymous
    September 09, 2003
    Make stores occur as late as possible and reads occur as early as possible and invert the order of them as much as possible according to the rules given for the clr:http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/480d3a6d-1aa8-4694-96db-c69f01d7ff2bMy suggestion above may not be the best way to surface these bugs, but it seems like somehting could be done along those lines.... Any help making multithreaded bugs happen more often seems like a great benefit.
  • Anonymous
    November 27, 2003
    I CDP to fix this exception would be nice:Unhandled Exception: System.DllNotFoundException: Exception from HRESULT: 0x80131524.Generated when running code in a created domain. The code works fine in the default domain, but break for some unknown reason in a domain created viaAppDomain newDomain = AppDomain.CreateDomain("New"+FriendlyName)
  • Anonymous
    March 27, 2004
    The comment has been removed
  • Anonymous
    April 11, 2004
    One thing that I would find useful would be to know if a disposable object has been disposed via its finaliser rather than explicitly in code.
  • Anonymous
    April 11, 2004
    Free books for students, teachers, and the classic enthusiast.
  • Anonymous
    June 02, 2004
    The comment has been removed
  • Anonymous
    June 03, 2004
    ah, well, wasnt the right place to post that question. Anyway, if I can help someone else... I never got BinarySearch to work. I used 'Contains' instead and it works beautifully. Here is the code:

    ArrayList ary = new ArrayList();
    string test = eventArgs.Item.Cells[5].Text;
    if (!ary.Contains(test))
    ary.Add(test);
  • Anonymous
    July 27, 2004
    The comment has been removed
  • Anonymous
    June 08, 2009
    PingBack from http://jointpainreliefs.info/story.php?id=2900