Inside Static Constructor (.cctor)

The primary objective of using a static constructor (also known as, type constructor, class constructor or .cctor) is to initialize static members of a type, or performing some operations, which seems to be preconditions for performing any operation on a particular type, or an instance of the type. Furthermore, it is useful in creating wrapper of unmanaged classes, when the constructor can call LoadLibrary method.

It can only be defined as a static member of a type as follows:

public class StaticConstructorDemo{
    static ILogger _logger;
    static StaticConstructorDemo(){
        // ... initial setup 
        _logger = new TextLogger();
    }
}

Few notable facts about static or type constructor:

[1] Type constructor will be called just once after its being loaded in the application domain. Timing when it will be called is completely depends on CLR.  But it will surely be called before instantiation of any object from the type or before any invocation of a static method. So, it might be the right place for executing those codes that are needed to be executed just once and before any methods (static/instance) of the class invoked. There is not specific order mentioned for execution of .cctor in inheritance/association scenario. Order on which the .cctor will get executed completely depends on the CLR.

[2] Type constructor is thread safe. So, only one thread in the app-domain can run this constructor, as CLR ensures the thread safety of .cctor. If multiple thread try to access a .cctor, only one thread will eventually be successful to get a mutually exclusive lock on the type constructor while other thread will be blocked. After the current thread complete its execution of .cctor, other thread will wake up and monitor that .cctor has been executed before. Hence, they will just return without executing the .cctor.

[3] Any access modifier before the type constructor is not allowed, otherwise it results in following compile time error: “access modifiers are not allowed on static constructors“.

[4] It does not accept any arguments, and can be applied to both value and reference types.

Exception Handling

Consider following code–

public class StaticConstructorExceptionDemo{
  public static int Result = 0;
  static StaticConstructorExceptionDemo{
    int test = 0;
    Result = 100/test; // throws DivideByZeroException
  }
}

When static property Result is accessed for the first time (after being loaded in the current context), we expect a DivideByZeroException to be thrown from StaticConstructorExceptionDemo(). In contrast, it gets TypeInitializationException.

However, it is worth noticing that the _innerException is actually pointing to an instance of DivideByZeroException.

Therefore, please underscore the following important points while handling exceptions related to type constructor.

[1] We should not throw exception from the type constructor unless we come to a conclusion that the type is unusable for further usage. Due to any unhandled exception, type becomes completely unusable in the currently loaded appdomain (context).

[2] In case of any exception inside type constructor, we should expect an instance of TypeInitializationException, which refer to the original exception as its inner-exception.

Performance Optimization

By utilizing static members, we get motivated to implement singleton pattern in the following manner–

	public class FileSystemLogger:ILogger
	{
	public static FileSystemLogger Instance =
	new FileSystemLogger();
	// ILogger Implementation
	}

view raw gistfile1.cs hosted with ❤ by GitHub

Alternatively, we can implement it by utilizing by introducing a type constructor:

	public class FileSystemLoggerWithCCTOR:ILogger{
	public static FileSystemLoggerWithCCTOR Instance;
	static FileSystemLoggerWithCCTOR(){
	Instance = new FileSystemLoggerWithCCTOR();
	}
	}

view raw gistfile1.cs hosted with ❤ by GitHub

Although both class functionally looks quite similar, there is a subtle difference between them. If we fire up ILDASM, we can see an extra attribute added in FileSystemLogger, which is missing in FileSystemLoggerWithCCTOR— “beforefieldinit”.

According to MSDN, it “specifies that calling static methods of the type does not force the system to initialize the type“.

As we can see, in first class FileSystemLogger, CLI mark the class with beforefieldint that means that calling the methods of FileSystemLoggerdoes not enforce static field initialization. The reason CLI does this: as per CLI specification, it is expensive to ensure that static fields are initialized before any of the static method get called. When multiple application domain comes into account, it become more expensive.

However, CLI enforce static field initialization when any of the static field is accessed. On the other hand, FileSystemLoggerWithCCTOR has a static constructor which results in an assurance from the CLI that static constructor will get called before any static member would be invoked, which in turn, initializes all the static members of the class. However, that means, performance optimization using beforefieldinit is no longer possible with this implementation.

Conclusion

We have to use type constructor with care. We should consider not to use type constructors as long as we can, to enable performance optimization by CLI via beforeFieldInit.

Hope it helps. Thanks for visiting the blog!

---

See More

[1] C# and beforefieldinit
[2] Static Constructors Demystified
[3] CLR via C#
[4] Static Constructor on MSDN

---

Revisions

[R-2: 30-03-2013] Minor formatting changes.
[R-1: 29-03-2013] Updated formatting to make this post more consistent with current CSS.