A customer has reported a bug. Being one of those educated and smart customers we love, he sent us the repro steps and the input data.
When I first saw the bug report, I thought it will be really hard to repro it, but, to my surprise, I’ve been able to repro it from the first try.
Good, let’s move into debugging …
Everything works ok, until we’re returning a value in an Office ribbon callback method. That’s where PowerPoint raises an exception and stops calling other callbacks. I had to modify the code a little to make it debuggable (it has been written in fluent paradigm and there was no other way of finding out the culprit).
And … surprise: the callback returns 1500, which is probably too large for PowerPoint to handle and this is why the other callbacks are never called – PowerPoint stops processing this request and moves on to other requests.
Why would the callback return 1500, since it should have returned something below 30? Here’s where karma bit me: I’ve optimized some code to use internally some lists and return these lists. The code worked fine for years, until a rookie had to use my code.
My original code:

public static class AvailableDateFormatsManager
{

private static readonly List _formatsListA = …
private static readonly List _formatsListB = …

public static List GetAvlFormats( {criteria} ) …

}

Rookie’s code:
public List GetAllAvlDateFormats( …)
{
var list1 = AvailableDateFormatsManager.GetAvlFormats( criteriaA ); // returns _formatsListA
var list2 = AvailableDateFormatsManager.GetAvlFormats( criteriaB ); // returns _formatsListB
list1.AddRange( list2);
return list1;
}

All names are meaningless and stupid, all you have to do is to notice how I’ve broken the encapsulation by returning the actual private List object instead of returning an IEnumerable or a ReadOnlyCollection.

Advertisements