拡張メソッドがまだ機能する場合、静的コンストラクターが失敗して例外をスローするかどうか疑問に思っていますか? ロガーは、拡張メソッドの問題を検出するのに役立つことを目的としています。それでもうまくいかない場合は、catch を試して、コンストラクターが成功することを確認する必要があります。コードを呼び出してエラーをログに記録できることを願っているので、例外をスローできるようにしたいと思います。(これは、私が考えているものに似た単なるサンプルコードです)
public static class Extensions
{
private static readonly log4net.ILog log;
private const TIME_TO_CHECK;
static Extensions()
{
log = log4net.LogManager.GetLogger (System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); //could maybe throw exception
TIME_TO_CHECK = readInFromFile(); //could maybe throw exception }
public static DateTime StartOfWeek(this DateTime dt, DayOfWeek startOfWeek) {
int diff = dt.DayOfWeek - startOfWeek;
if (diff < 0) {
diff += 7;
}
return dt.AddDays(-1 * diff).Date;
}
}
私は周りを検索しました(これが繰り返されないことを願っています)、静的コンストラクターから例外をスローすることは一般的に良くないことがわかりました。ほとんどの場合、クラスはインスタンス化できるものであり、すべてが拡張メソッドではなかったと思います。