TypeLoadException hiding inner exception

Question

Hi

I'm using Compact Framework 3.5 / VS2008. I'm getting really odd behavior with TypeLoadException. The following code throws this error. The reason is a problem with the database connection. However for some unknown reason this inner exception is lost and is not contained in the TypeLoadException.

try
{
    settingsFromDb = SettingsFromDbManager.Instance;
}
catch (Exception ex)
{
    throw ex; // BREAKPOINT HERE
}

If we look at the SettingsFromDbManager class below it can be seen that it is a simple singleton class. The database error is occurring in the Load() method. I haven't included this code in the sample. If I put a breakpoint at the position indicated in the sample below I can see a database error. Unfortunately if I put a breakpoint in the position indicated in the code above then all I get is the TypeLoadException with no inner exception. There is nothing to indicate that a database problem occurred. This is bad :( Does anyone know why this strange behavior could be happening??

Cheers
Mark

public sealed class SettingsFromDbManager
{
    static readonly SettingsFromDbManager _instance = new SettingsFromDbManager(); 

    SettingsFromDbManager()
    {
        try
        {
            Load();
        }
        catch (Exception ex)
        {
            throw ex; // BREAKPOINT HERE
        }
    }

    public static SettingsFromDbManager Instance
    {
        get
        {
            return _instance;
        }
    }

    .... more code ...
}

** Update **

Thanks very much for all the great suggestions and help!

Pierre I used the test class you so kindly wrote. Here's the code I called it with. It must be a quirk of the Compact Framework I guess because when I examined the exception it was TypeLoadException with no inner exception :(

try
{
    Fail.Test();
}
catch (Exception ex)
{
    var x = ex.ToString(); // BREAKPOINT HERE
}

I think VinayC is probably correct about the reason. This is all a bit beyond my knowledge. Not sure what to do now. I don't want to give up my Singleton classes - they are useful. I'm using the "fourth version" Singleton pattern from http://csharpindepth.com/Articles/General/Singleton.aspx. I haven't used them before but seemed like a good idea to share the same instance of some utility classes around the application rather than creating and disposing them numerous times. Performance is a big issue with the Compact Framework.

* Update *

WOO HOO! All I had to do was change the Singleton class as follows. It instantiates the class in the property getter. Now my exceptions bubble to the surface as expected :)

public sealed class SettingsFromDbManager
{
    static SettingsFromDbManager _instance = null; 

    SettingsFromDbManager()
    {
        try
        {
            Load();
        }
        catch (Exception ex)
        {
            throw new Exception("Error loading settings", ex); 
        }
    }

    public static SettingsFromDbManager Instance
    {
        get
        {
            if (_instance == null)
                _instance = new SettingsFromDbManager();

            return _instance;
        }
    }

    .... more code ...
}

Answer 1

There is no good reason why the exception raised in the static constructor would not show up in your original call location. However, I don't understand why you do not get the System.TypeInitializationException instead, which should be the exception thrown in case your static constructor fails.

Here is a piece of sample code which throws System.TypeInitializationException with an inner exception set to the "failed" exception:

class Fail
{
    static Fail()
    {
    }

    Fail()
    {
        throw new System.Exception ("failed");
    }

    static readonly Fail instance = new Fail ();

    public static void Test()
    {
    }
}

I would investigate further to understand why you are getting a TypeLoadException instead, which should occur when an assembly cannot be properly loaded or initialized (TypeLoadException Class in MSDN).

Answer 2

From what I know, static constructors may run on a different thread (or more specifically on different call chain) - its a guarantee from runtime that they will be invoked before type is accessed. Exception in the static constructor will mark type as not usable for the app domain. When type is accessed, you will get an TypeInitializationException (as per documentation) but exception occurred within type constructor will not come as inner exception because its not on same call chain - for that matter static constructor might had been executed quite before. Only puzzle out here is TypeLoadException instead of TypeIntializationException as Hans has pointed out.

Edit: Here's the article that explains lazy/eager semantics of type initializers. Your code can be eager implementation (i.e. static constructor may get invoked even before first access to type field)