Damir's Corner.

Static Class Constructors Should Never Throw an Exception

I've spent a few hours today hunting down a mysterious bug which caused the program to keep reporting failed connections to database server although it was already available for hours. In the end it was a problem of incomplete exception handling but it's interesting how the problem manifested itself. Let's look at the following sample code.

using System;  
using System.Collections.Generic;  
using System.Text;

class Program  
{  
   static string source;

   class Static  
   {  
      static Guid problem;

      static Static()  
      {  
         // will cause an exception if not a valid guid  
         problem = new Guid(Program.source);  
      }

      public static void Write()  
      {  
         // will only succeed after successful type initialization  
         Console.WriteLine("Success!");  
      }  
   }

   static void Main(string[] args)  
   {  
      // setup invalid GUID source value  
      source = String.Empty;  
      Console.WriteLine("Invalid source value: \"" + source + "\"");  
      try  
      {  
         // type initializer will fail here  
         Static.Write();  
      }  
      catch (Exception e)  
      {  
         Console.WriteLine("Exception: " + e.Message + "\n\t" + 
            e.InnerException.Message);  
      }  
      // setup valid GUID source value  
      source = Guid.Empty.ToString();  
      Console.WriteLine("Valid source value: \"" + source + "\"");  
      try  
      {  
         // type initializer should succeed here  
         Static.Write();  
      }  
      catch (Exception e)  
      {  
         Console.WriteLine("Exception: " + e.Message + "\n\t" + 
            e.InnerException.Message);  
      }  
      Console.ReadKey();  
   }  
}

Ok, there's no database access here but just imagine that the Guid constructor call is the database access attempt. As you can see, the first call simulates that the server is down while at the second call the server is back up. Keeping that in mind the first call should fail while that second one shouldn't. (For those of you not familiar with static constructors: they get executed before the first (static or instance) property access or method call. As such they take care of type initialization.) Let's take a look at the program output then.

Exception: The type initializer for 'Static' threw an exception.  
   Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).  
Valid source value: "00000000-0000-0000-0000-000000000000"  
Exception: The type initializer for 'Static' threw an exception.  
   Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Obviously both calls have failed. Why is that so?

It turns out that the static constructors are executed exactly once. If they throw an exception, it gets wrapped as an InnerException of the TypeInitializationException. Any attempts to use this class afterwards don't cause the constructor to execute again, but just make it throw the same exception once again. Therefore the method call still reports an invalid GUID value (or in my case failed database connection attempt) although the problem has already been remedied. This makes the class effectively unusable within the AppDomain.

The lesson to be learned: no matter what you're doing in the static constructor, never allow it to throw an exception unless the problem is indeed fatal and you intend to quit the program immediately. In all other cases provide reasonable defaults and handle changed circumstances elsewhere in the code.

You can find some additional technical details in Chris Brumme's blog entry.