C#

Bad mix: Enumeration and Switch in C#

Chris Han — Mon, 24 Jul 2006 16:55:00 GMT

“The great power comes with a great responsibility.“

C# as a powerful language has reduced the mistakes in Switch/Case flow control by removing the implicit fall-through behavior. That says you can not pass the compilation without an explicit statement at the end of each case, either a “break”, a “return”, a “goto”, or you can also detour the control flow by “throw” an exception. AS a matter of fact, you should always throw an out-of-boundary exception at “default” case, unless you have a default value specified by the business requirement. Otherwise it’ll be very hard to find a problem at runtime such as the caller providing a parameter which is out of the enumerator’s scope and it is being tested at the “switch” in the callee module.

Try code below, it is a real scenario but simplified. The root cause in this case is a bug in C# enumeration type – you can pass compile-time inspection by providing 0 even when 0 is not defined in the enumeration.

But if we have had a “default” case in the switch structure, it will be a lot easier to identify the problem.

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Text;

using System.Windows.Forms;

using System.Diagnostics;

namespace WindowsApplication1

{

public partial class Form1 : Form

{

public Form1()

{

InitializeComponent();

}

private void Form1_Load(object sender, EventArgs e)

{

}

private enum enuPath:int

{

a =1, // enum starts from 1, 0 is not in the scope

b ,

}

private void button1_Click(object sender, EventArgs e)

{

NewMethod(0); // C# bug: you are able to pass in 0 which is out of the scope of enuPath

}

private static void NewMethod(enuPath EnuPath)

{

//int path = Convert.ToInt32(enuPath);

try

{

switch (EnuPath)

{

case enuPath.a:

Debug.WriteLine("In case 1\n");

break ;

case enuPath.b:

Debug.WriteLine("In case 2\n");

break;

case enuPath.c:

Debug.WriteLine("In case 3\n");

break;

//default:

// throw new Exception("suplied parameter is out of scope of enuPath");

}

Debug.WriteLine("You are not supposed reach here since 0 is not an acceptable value\n");

}

catch (Exception ex)

{

Debug.WriteLine("In exception\n");

}

I'm glad I saved couple of calories by switching to .NET (The truth of C++)

Chris Han — Mon, 20 Mar 2006 16:28:00 GMT

I couldn't stop laughting every time I'm reading this article.

No matter it's truth or just a parody. I'm sure it'll give you a smile when you look back the years in your coding career. Check out the article:

http://geekswithblogs.net/chrishan/articles/72646.aspx

Even funier and/or scarier is that it sounds so real that many of my firiends and geeks here ask me if it's real when they read of it after my last post.

:-DDD

Happy coding!

A basic difference between value types and reference types in .NET's Common Type System

chrishan — Wed, 09 Nov 2005 20:02:00 GMT

David Chappell in his article “Understanding .NET's Common Type System“ explains “A basic difference between value types and reference types is that an instance of a value type has its value allocated on the stack, while an instance of a reference type has only a reference to its actual value allocated on the stack. The value itself is allocated on the heap“

http://www.awprofessional.com/articles/article.asp?p=24456&redir=1

This is the best comment I've ever read. I'd like to keep it here for myself.

Statics & Thread Safety

chrishan — Fri, 04 Nov 2005 11:13:00 GMT

I had the discussions with my friends on this Statics & Thread Safety issues long time ago. It started with a weird “session swap” issue in one of our web application where we use “static” field to store the return value for an user profile int the data access component. The problem is only captured in a stress test but not unit test. That so reminds me another interesting topic on testing method I'd like to talk about in a seperate post.

I see many developers new to C# repeating the mistake I made lately. I guess one reason is the misleading by MS's document itself. Many places in MSDN have the remark in the “Thread Safety” section: "Any public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe." I believe Microsoft says so is because they wrote the code in a thread safe manner.

The general idea is that static method is not a problem, but static variables where you store data. A local variable inside a method (even a static method) exists on the stack one for each thread. It's private to a thread of execution as long as it's not “static“. A static variable will be shared by all threads, that's problem! (Unless it's read only)

I found Scott Allen's article is the best so far in this topic. You can read it here:

http://odetocode.com/Articles/313.aspx

http://odetocode.com/Articles/314.aspx

Scott demonstrate the basic lock/Synchronization mechanisms in his article too. But be aware of dead-lock issue when you go that path. For more information, here is a guideline from MSDN I feel usefull:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconthreadingdesignguidelines.asp

I haven't tried to see how it behaves on a server farm configuration. I feel cross-server locking will be hard or too expensive to implement. I'm going to post it here once I got time. If you have such experience. please let me know.