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!