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 ステータス コードであり、消費者に合理的または可能性のある回答を提供するために最善を尽くします。