MVCグローバルエラー処理パターンコードの匂い

Question

public ActionResult Foo(int id) 
{ 
    if (someCheckFails) 
    { 
     Log.Error(new SomeTypeOfException()); 
     return View("SomeErrorView"); 
    } 

    return View(); 
} 

上記のコードは、エラーが記録され、失敗条件が満たされた場合（Unauthorized、FileNotFoundなど）にリダイレクトされます。

これは私にとってはまったく臭いではありません。 DRYに違反し、私はロガー以外の場所に決して行き渡らない例外を作成しています。

同じことが、よりよい読み取る乾燥機であり、MVCと思われる上記の例外の種類を記録し、リダイレクトするGlobalFiltersを設定することにより達成され、次いで、単に任意のアクション

public ActionResult Foo(int id) 
{ 
    if (someCheckFails) 
     throw new SomeTypeOfException(); 

    return View(); 
} 

から投げることができます方法。しかし、実際に何が起こっているのかは、フローコントロールの例外を使用してであることが私には分かります。

これについてのご意見はありますか？上記のスニペットをお好みですか？それとも私が逃した三つ目の方法がありますか？

Answer 1

あなたがチェックしている内容によって異なります。 Actionメソッドを実行する前の何かであれば、ActionFilterAttributeから継承した独自のAttributeをコーディングし、OnActionExecutingメソッドをオーバーライドしてfilterContext.Resultを設定することができます。

私は以下の例が含まました：

[Security(Privileges = "Test")] 
public ActionResult Index() 

あるいはにGlobal.asaxの中でそれを含める：あなたは、その後のアクションメソッド、コントローラーを飾るために、この属性を使用することができます

public class SecurityAttribute : ActionFilterAttribute 
{ 
    public string Privileges { get; set; } 

    public string FailureUrl { get; set; } 

    public SecurityAttribute() 
    { 
     this.FailureUrl = "~/Home/PermissionDenied"; 
    } 

    public override void OnActionExecuting(ActionExecutingContext filterContext) 
    { 
     if (string.IsNullOrEmpty(this.Privileges)) 
     { 
      throw new InvalidOperationException("Privileges must be set."); 
     } 

     if (!SecurityHelper.IsPrivileged(this.Privileges)) 
     { 
      filterContext.Result = new RedirectResult(this.FailureUrl); 
     } 
    } 
} 

を

public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{ 
    filters.Add(new SecurityAttribute()); 
} 

Answer 2

私は、しばしば答えは「それは依存している」と考えています。

実際に例外のある場合は例外を使用して、の動作をします。チェックが特定の状況下で失敗すると予想される場合、たとえばAdrianの応答に示されているようなアクセス権の管理は例外ではありません。私は議論するだろう：実際にはエラーではないので、その場合はチェックしてリダイレクトする。

実際に例外が発生してフローが効果的に中断された場合は、例外を使用してください。例外をスローするたびにログエントリを書き込むことに頼るのではなく、そのアプローチのために書かれたファシリティに例外的なケースのロギングを処理することは良い考えです。第2のアプローチは実際にDRYerです。