私はDarinの答えが好きですが、ASP.NET MVC Web APIフレームワークは内部的に例外を抑制/処理していて、Global.asaxのApplication_Errorメソッドにヒットするために再スローしていないため、このケースではうまくいきません。私たちのソリューションはこれです。
私はそうのようなカスタム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レスポンスの内容を変更して、特定のHTTPステータスコードが表示された場合にIISがデフォルトのHTMLエラーページを挿入しないようにすることもできます。
私がこれを持っている唯一の問題は、Web APIの今後のリリースで変更することを願っています。彼らは例外をbase.SendAsyncから返されたタスクに戻して送信していないということです)。だから、私たちがやらなければならない唯一の情報は、HTTPのステータスコードであり、消費者に合理的または可能性のある回答を与えるために最善を尽くしてください。
これは何とか間違っています。どこかの図書館に例外を投げていますか?コントローラーで例外をキャッチして、自分が選択したエラービューを返すのはなぜですか? –
これはASP.NET MVC Web APIを使用しているため、コントローラからビューを返すことはありません。 JSON/XMLレスポンスを返します。私はまた、コントローラに到達する前に例外を処理する方法が必要であると私の質問で言及します。今は、コントローラーの中にいたらどこにでも例外をキャッチするExceptionFilterがありますので、すべてのアクションでtry/catchを行う必要はありません。 – phreak3eb
私はあなたの質問を完全に理解しているとは思わない。どんな種類のエラーを正確に捕まえようとしていますか? – cecilphillip