What are the most controversial C# or .NET “features” you would consider “bugs”? [closed]

Question

What do you consider a bug in C#, or .NET framework that Microsoft will not fix, or hasn't fixed yet?

I'm hoping the answers to this question will give us better patterns to work from, and build more robust code.

Answer 1

That you have to check if an event if null before raising it

public event EventHandler SomeEvent;

public void RaiseEvent()
{
    if (SomeEvent != null)
        SomeEvent(this, null);
}

If listeners are connected, then the event contains a list of listeners, if no listener is connected, it is null (instead of just an empty list). This behavior has existed since .NET 1.0, and to me highly illogical.

Answer 2

All references are nullable by default

Anders Hejlsberg who is considerd the "father of C#" even said this was a mistake in a Computerworld interview:

50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.

Answer 3

Out of range ints as enums.

You can cast an out-of-range enum from an int and the compiler is fine with it:

enum Colour
{
    Red = 1,
    Green = 2,
    Blue = 3
}

Colour eco;
eco = (Colour)17;

See here for a longer discussion (and some replies).

Answer 4

The requirement for break statements in a switch, even though fall-through is not allowed anyway.

switch (myvalue)
{
    case 1: DoSomething();
    case 2: DoSomethingElse();
}

Won't work (compile error). You have to

switch (myvalue)
{
    case 1: DoSomething();
        break;                     // AARGH!

    case 2: DoSomethingElse();
        break;             
}

Mysteriously, however, this works:

switch (myvalue)
{
    case 1: return something;
    case 2: return somethingElse;
}

If you try to put the break statements in after the return statements, you will get an "Unreachable code detected." compile error.

Answer 5

Closures

It may not look like it but the following code will print 10 on every line...

// In Example3a.cs
static void Main()
{
    // First build a list of actions
    List<Action> actions = new List<Action>();
    for (int counter = 0; counter < 10; counter++)
    {
        actions.Add(() => Console.WriteLine(counter));
    }

    // Then execute them
    foreach (Action action in actions)
    {
        action();
    }
}

Fixed version:

// In Example3b.cs
static void Main()
{
    // First build a list of actions
    List<Action> actions = new List<Action>();
    for (int counter = 0; counter < 10; counter++)
    {
        int copy = counter;
        actions.Add(() => Console.WriteLine(copy));
    }

    // Then execute them
    foreach (Action action in actions)
    {
        action();
    }
}

To learn why this is, check out this article by John Skeet

Answer 6

This is going to be controversial :)

Garbage Collection

Now, I've been involved with this since Java first came out (I went to a "w00t" presentation about Java at Hursley Park many years ago where a chap told us all how wonderful it was, and mentioned GC. Did you know Java initially didn't even have finalisers? Crazy, everyone at that meeting told the presenters just what a stupid idea Java was because of that). And Microsoft decided that a GC was the way to go with .NET, but although they had finalisers they didn't really like it when a quite vocal group of us on the Microsoft forums told them a lack of deterministic finalisation was a mistake. They added the IDispose as a pattern shortly afterwards, and the using keyword a few years later.

The moral of the above stories is that 2 developers of new languages just didn't quite get it. They added a great cool feature where you no longer had to worry about alloc/free of memory manually, the language feature would take care of it for you and you no longer had to worry our pretty little heads about it.

Only the problem is that they forgot something. Garbage collection is great for memory management. It is useless at object management.

Most applications revolve around object lifetimes, they don't really care to much about memory except as a 'container' to hold your objects. So having GC that frees up your memory isn't going to cut it, except in those cases where your object is simple and contains nothing more than memory anyway (which, ok, is 90% of all objects - but who cares about the simple stuff when you have complex stuff to build).

So because of this, we have the situation where we not only have various features added to the language to attempt to make up for the deficiencies, but we also have to manually manage the object lifetimes as well!

In a RAII-based language, object lifetimes are easily managed. In a GC one, we have to not only implement special IDispose methods (in addition to the finaliser, and make sure they do not conflict with issues like double-deletion, etc), and 'smart pointer' classes like SafeHandle, but we also have to manually put using statements in to ensure they are called, and remember to write your exception handling code correctly so your objects won't leak. You also have to understand what the internals of your libraries are doing, or you end up with leaks such as those when not manually un-associating event handlers on a GUI.

How wonderful this 'automatic', 'no worries' memory management mechanism is!

So, remember that GC is great for memory, bad for objects, and the problem is that the language designers didn't make a distinction between the two equating objects == memory.

The fix is of course to split the distinction. Imagine if objects were treated separately, with full automatic scoping using smart pointers. The memory underlying the object can still be allocated and freed using the GC, but the destructor (I hesitate to use either finalise or dispose as they're both band-aids) can then be implemented in a RAII fashion. Thus you'd get the best of both worlds - fast, no-leak memory, and deterministic object finalisation.

Answer 7

Allowing any object to be used as a lock

You can synclock on any object. I'm not really sure why this is the case. Maybe the ease of writing 'synclock (this)'?

There are several consequences of this decision:

• The easiest locking code to write is subtly wrong. If you 'synclock (this)', anyone who has a reference to your object can also hold that lock. They can accidentally create deadlocks. For example if you internally run an operation asynchronously, and it needs the lock, then a user 'helpfully' holding the lock over a couple operations will prevent them from completing.

• Locking overhead. Every object needs a place to store their locked state and so forth. If you store it in the object then you have a space overhead on every instance of the object. If you store it in a table then you have a time overhead on every locking operation to indirectly access the data.

• Framework overhead. The ability to lock on any object creates mysteries for programmers. What happens if you try to lock on a boxed value type? Is locking on null allowed? Do two boxed value types with the same value correspond to the same lock or different locks? What about nullable values? Null nullable values? Does casting maintain lock identity? If I mutate the object I'm locking on, does it now correspond to a different lock? If I'm holding an object as a lock, is it safe to garbage collect? Dispose? Finalize? Resurrect? Can using an instance of type X as a lock introduce possible deadlocks if I'm also using it for its intended purpose?

Personally, I would have gone with a specialized lock class. If you want to hold a lock, you use an instance of the special class. This has the nice effect of hiding locks by default and naturally allowing for different types of locks (read/write, up-to-n, non-re-entrant, etc).

Answer 8

I would consider cold-loading times so bad that it's a bug. This is what is holding .Net back from being a first class environment for client apps. For instance, consider that on a freshly booted machine, it will often take upwards of 5 seconds to launch a simple WPF app that doesn't display anything but a blank window.

In what other environment do people put up with this? Java has the same problem, that too is primarily a server framework because of this. This problem reduces .Net on the client to being confined to in-house enterprise development (where users don't really have any choice). No one in their right mind would develop client apps for the masses in this environment.

Answer 9

Using() may cause object initializers to leak if an exception is thrown

If an exception is thrown within a using statement then its possble that the objects may not get properly disposed of.

For a detailed explanation of this see this article. Many people have considered this to be a bug, however this is by design.

Eric Lippert's response:

The behaviour is correct and desirable. The spec is extremely clear on this point and if an implementation of C# does not have this behaviour, they have a bug.

The spec clearly states that "using(T x = y) s;" means exactly the same thing as "{ T x = y; try { s; } finally { ... code to dispose x ... }". That is, the initialization is done outside the try-protected region, precisely so that if it fails, we do NOT attempt to clean it up. That would be dangerous.

The spec also clearly states that "t = new T() { X = x };" means exactly the same thing as "T temp = new T(); temp.X = x; t = temp;". That is, the assignment to the variable happens after the object is known to be in its fully initialized state.

These two designs work together to ensure that you never dispose a partially initialized resource. If you have a situation where you need to handle disposing of partially constructed resources then you need to write the code yourself to do that; there's no way we can generate the code for you and have any confidence that it is right. Any operation on a partially initialized resource is potentially hazardous.

Based on that answer I'm considering using the try..catch..finally blocks to ensure proper cleanup of my code if an exception occurrs, as opposed to using statements.

Answer 10

I don't think everyone will agree but I would say their entire Ajax implementation and more specifically the UpdatePanel.

The fact that the entire page renders and gets sent back to the browser and then just a small piece of it is used completely undermines the entire concept of Ajax and just going back to the server to get what you need. Seems very hacky to me.

I am aware there are other implementations but for the Microsoft one to be so inefficient I would consider that a bug.

Answer 11

InternalsVisibleToAttribute

This attribute allows one assembly to be able to see internal methods, properties, and members of another assembly. This is just plain poor development practice.

Though I do not know for sure why it exists, I believe they introduced it along with their own unit test framework in order to let unit tests be able to access internals in the classes that they test. This is obviously the wrong way to write tests, as tests should test the public interface of a class.

And it is hard to explain to coworkers that are not that experienced with unit tests that I am right, and MS is wrong.

Answer 12

What has bugged me lots of times already is that the XmlReader doesn't expose the stream position of a given tag, although it has that information internally.

For example I have a N GB XML stream and I need to separate a header with meta information from an inner document with the content (a quite common scenario for example in BizTalk).

To do that stream based (a must when processing multiple big documents) with .NET you have to implement something close to a full blown XML parser which then does expose the stream position. And that's not the way it should be.

Answer 13

The fact you can't properly load a control by classname/assembly kills me every time.

And it still hasn't been fixed:

http://stackoverflow.com/questions/450431/dynamically-loading-a-usercontrol-with-loadcontrol-method-type-object

Answer 14

Interating through a null collection with foreach throws an error. IMHO, it should just continue on. Yes I understand that it's null, but it's just annoying as annoying can be, and a real gotcha for newbies.

Answer 15

The TotalHours of a Timespan doesn't correctly show above 24hours without using Math.Truncate. Although this is not a bug its weird functionality I believe. Has caught me out a few times when I was learning.

Edit:

Example: http://stackoverflow.com/questions/3505230/format-timespan-greater-than-24-hour

Answer 16

ObjectDataSource is very difficult to extend. You have to use reflection to access private/internal members in order to do anything useful.