Apparently Microsoft has no easily accessible place to report bugs in their programming languages, so I’m posting it here and hopefully someone who can fix it will eventually read it (and maybe even put an easy-to-find link up to report bugs on MSDN?)

If it’s not a bug with .NET itself, perhaps someone can tell me what I’m doing wrote here, C# newbie that I still am.

I have a DataGridView bound to an ArrayList of objects of the following class:

public class SeriesPoint : IComparable {
    private double _price;
    public DateTime? Timestamp;

    public double Price {
        get { return _price; }
        set { _price = value; }
    }

    public string Date {
        get { return Timestamp.ToString(); }
        set { Timestamp = DateTime.Parse(value); }
    }

    public SeriesPoint() { _price = 0; Timestamp = null; }
    public SeriesPoint(double p, DateTime? d) { _price = p; Timestamp = d; }

    //These are compared only based on date.
    public static bool operator<(SeriesPoint lhs, SeriesPoint rhs) { return lhs.Timestamp < rhs.Timestamp; }
    public static bool operator>(SeriesPoint lhs, SeriesPoint rhs) { return lhs.Timestamp > rhs.Timestamp; }

    //Equivalent in C++: return rhs.timestamp == timestamp;
    public override bool Equals(object obj) {
        if (obj == null || !(obj is SeriesPoint)) return false;
        if (obj == (Object) this) return true;

        return ((SeriesPoint) obj).Timestamp.Equals(Timestamp);
    }

    //Nothing special about how it's hashed.
    public override int GetHashCode() {
        return base.GetHashCode();
    }

    public int CompareTo(object other) {
        //Nulls to the beginning.
        if (this == null && other != null) return -1;
        if (this != null && other == null) return 1;

        if (this < (SeriesPoint) other) return -1;
        if (this > (SeriesPoint) other) return 1;
        return 0;
    }
}

And I run the following to attempt to find the last null value in a sorted list:

int lastnull = sortedpoints.LastIndexOf(new SeriesPoint(0.00, null));

This actually works, but when the function exits and control presumably returns to the main loop, the program suddenly crashes with the following exception in Application.Run() (not even running on the same thread as my code!):

“An unhandled exception of type ‘System.InvalidOperationException’ occurred in System.Windows.Forms.dll

Additional information: Operation is not valid due to the current state of the object.”

I checked all of my code, put try blocks around things, made sure nothing was throwing when it shouldn’t be, removed functions, rewrote functions, reordered functions, checked boundary conditions… nothing. My code is running fine and returning correct results. .NET is then crashing. I have no idea why, but the data binding is definitely a possibility.

I suppose my best course of action is to remove the Equals() method (this fixes the problem) and rewrite my code without it.

Am I the only one who finds newer programming languages, such as Java and C#, to take strong typing to a very undesireable extreme? It seems like a reaction to most programmers not being able to get type safety right in C++, but it ends up making the code look awful, obscuring its function, and requiring a lot of extra work to explicitly cast things around. Especially when working with arrays, it oftentimes requires creating entirely new loops dedicated solely to the purpose of casting. This is stupid in many different ways. ConvertAll sort of helps, but it’s clunky and doesn’t work for collections. Also, why does the cast operator have lower precedence than the dot operator? I would think the other usage would be more common.

In Perl, which I now consider my favorite language (because it doesn’t presume to impose seemingly arbitrary restrictions on the programmer), you can join an array of doubles into a string in one line of code. You can do it in two in C++, which isn’t bad, since the stream operators have overloads for numeric types. Try it in C# or Java and you’ll need at least four or five lines.

I think I prefer the flexibility of weak typing despite the added risk. It’s a pity that “hot” languages are all following the “programming with mittens” paradigm right now.