Static constructor should not wrap actual exceptions in TypeInitializationException

[MhAllan]

I am writing some generic tools, and I want the static constructor to do some reflection work on the generic type so this reflection takes place only once. The problem is that the exceptions thrown from static constructors are wrapped in TypeInitializationException that doesn't tell much. And my specific exception goes under it's inner exception.

It is hard to accept this behaviour. If this wrapping is not a must, then we should change this behaviour (instance constructors at the end don't have this problem), otherwise why don't we concatenate the error messages beside the inner exception, as not all devs and loggers care about inner exception, and I haven't seen anyone catching TypeInitializationException or aware of it!

class Foo
{
    static Foo()
    {
        throw new Exception("Foo Exception");
    }
}

Ideally expecting: Foo Exception
Unfortunately getting: The type initializer for 'SampleApp.Foo' threw an exception

[huoyaoyuan]

If this wrapping is not a must, then we should change this behaviour

It is a must and can't be changed.

as not all devs and loggers care about inner exception

It's their bug because InnerException is used in more places, like AggregationException from async code.

and I haven't seen anyone catching TypeInitializationException or aware of it!

The timing of static constructor isn't explicitly specified. There has to be an unique identifier for it since it's not included in call stack.
TypeInitializationException is fatal and hard to be recoverable. It's even unclear about where to catch it, so people can't catch it.

[MhAllan]

@huoyaoyuan then why don't we concat the inner message with the TypeInitializationException message?

[huoyaoyuan]

Because message represents the message at this level only.

InnerException is widely used in many cases. Exception.ToString prints inner exceptions recursively. Message isn't enough to log an exception.