11

まず始めに、はい、ExceptionFilterAttribute から継承する例外フィルターを作成して使用しています。ID フィルターの直後にアプリの起動時に構成に登録され、API 内のどこかでエラーが発生した場合でも、ほとんど期待どおりに機能します。

そうは言っても、API に到達する前に発生するエラーを処理する方法を探しています。

理由: YSOD や IIS HTML エラーを返したくありません。ロギングを正しく処理し、JSON 応答をユーザーに返すことができるように、常にカスタム例外フィルター/ハンドラーをヒットしたいと考えています。

現時点では、Fiddler を使用してリクエストを行い、w3wp.exe プロセスにアタッチして、global.asax の Application_BeginRequest メソッドにリクエストがヒットしたことを確認できます。その後、500 レスポンスを返すだけです。例外でコードを中断したり、その後ブレークポイントにヒットしたりすることはありません。IIS エラーを返しているようです。私たちはこれが起こることを決して望んでいません。これらの「低レベル」の例外をすべてキャッチしてログに記録し、ユーザーにとって意味のあるものを返す機能が必要です。

ASP.NET MVC Web API コードにヒットしているように見えるエラーを前に処理するためにできることはありますか?

4

1 に答える 1

4

ASP.NET MVC Web API フレームワークは例外を内部で抑制/処理しており、Global.asax の Application_Error メソッドをヒットするために再スローしないため、Darin の回答は気に入っていますが、このケースでは機能しません。私たちの解決策はこれです。

私は次のようにカスタム DelegatingHandler を作成しました。

public class PrincipalHandler : DelegatingHandler
{
    protected const string PrincipalKey = "MS_UserPrincipal";
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        setAnonymousPrincipal();

        request = InitializeIdentity(request);

        return base.SendAsync(request, cancellationToken)
            .ContinueWith(r =>
                              {
                                  // inspect result for status code and handle accordingly
                                  return r.Result;
                              });
    }
}

次に、それを HttpConfiguration に挿入して、ヒットする最初/最後のハンドラーであることを確認しました。Web API でハンドラーが機能する方法は、階層的な方法です。したがって、リクエストごとにヒットする最初のハンドラーは、応答でヒットする最後のハンドラーになります。少なくともこれは私の理解です。私が間違っている場合は、誰かが私を自由に修正してください。

public static void ConfigureApis(HttpConfiguration config)
{
    config.MessageHandlers.Insert(0, new PrincipalHandler());
}

このアプローチを使用することで、Web API とコントローラーからの応答で返されるすべての結果を検査できるようになりました。これにより、何かが期待どおりに返されなかった結果として発生する必要がある可能性のあるログを処理できます。また、特定の HTTP ステータス コードが検出された場合に IIS がデフォルトの HTML エラー ページを挿入しないように、返される応答の内容を変更することもできます。

これに関する唯一の問題は、Web API の今後のリリースで変更されることを望んでいるのですが、base.SendAsync() から返される Task で例外が返されないことです。したがって、必要な唯一の情報は HTTP ステータス コードであり、消費者に合理的または可能性のある回答を提供するために最善を尽くします。

于 2012-04-24T13:30:27.977 に答える