1

Silverlight クライアントからのエラーをログに記録する次のメソッドがあります。

[MethodImpl(MethodImplOptions.NoInlining)]
public static bool ErrorHandler(Exception error, bool showError = true)
{
    string callingMethod = new StackFrame(1).GetMethod().Name;

    //write log - call webservice
    //show error that some error happened if showError is true
}

私の問題は、アプリを実行して例外をスローするメソッドを呼び出すと、次のようにログに記録されることです。

<ThrowExceptionMethod>b__72: test

しかし、通常の (開発者以外のランタイム) を持っている人がこのアプリを実行し、例外をスローすると、次のようにログに記録されます。

b__72: test

これは、SDK Silverlight ランタイムによるものだと推測しているだけです。ほとんどの同僚が Silverlight SDK をインストールしているため、判断が難しいです...これがこの異常の理由であるかどうかを誰か確認できますか?

解決しました！

SDK ランタイムによるものではなく、匿名メソッドを呼び出したからです。次のコード行を追加しました。

var listStackFrame = new List<StackFrame>();

for (int i = 1; i < 20; i++)
{
    listStackFrame.Add(new StackFrame(i));
}

string callingMethod = string.Empty; //new StackFrame(1).GetMethod().Name;

foreach (var item in listStackFrame
    .Where(m => m != null && m.GetMethod() != null && !string.IsNullOrEmpty(m.GetMethod().Name) && m.GetMethod().Name.Contains("__")))
{
    callingMethod += item.GetMethod().Name + "->";
}

これがリソースをどれだけ消費するかについては心配していません。なぜなら、例外が発生した後、ユーザーは何をしていても停止してサポートに連絡するからです。

4

2 に答える 2

1

これは通常、実行しているのは実際にはyieldイテレーターまたは匿名デリゲートデリゲートであるためです（私が見逃している他のケースがあるかもしれません）。何が起こるかというと、コンパイラは実際に新しいメソッドを作成し、ほとんどの構文糖衣のクラスさえも作成します。

[CompilerGenerated] 属性を持たない最初のものを探して、以前のすべてのメソッド呼び出しを繰り返すことができると思います。

于 2012-05-16T12:06:52.843 に答える
1

これは、開発マシンと通常のマシンの違いに意味があります。

StackFrame 情報は、デバッグ ビルド構成で最も有益です。デフォルトでは、デバッグ ビルドにはデバッグ シンボルが含まれますが、リリース ビルドには含まれません。デバッグ シンボルには、StackFrame オブジェクトの構築に使用されるファイル、メソッド名、行番号、および列情報のほとんどが含まれています。

それはStackFrameのドキュメントからのものです。

于 2012-05-16T12:21:41.257 に答える