ASP.net MVC ne rattrape pas les exceptions

Dans deux applications différentes, l’une personnalisée l’autre l’application MVC exemple que vous obtenez avec un nouveau projet VS2008 MVC, [HandleError] n’attrape pas les exceptions.

Dans l’exemple d’application, j’ai:

[HandleError] public class HomeController : Controller { public ActionResult Index() { ViewData["Message"] = "Welcome to ASP.NET MVC!"; throw new Exception(); return View(); } public ActionResult About() { return View(); } } 

qui est juste le contrôleur par défaut avec une exception lancée pour le test.

Mais ça ne marche pas. Au lieu d’aller à la page par défaut error.aspx, elle affiche les informations de débogage dans le navigateur.

Le problème est apparu pour la première fois dans une application personnalisée sur laquelle je travaille, ce qui m’a amené à le tester avec l’exemple d’application. En pensant que cela avait quelque chose à voir avec les modifications que j’ai apscopes à l’application personnalisée, j’ai laissé l’exemple d’application inchangé avec l’exception (beurk) du jet dans la méthode d’index.

Je suis déconcerté Qu’est-ce que je rate?

Dans Web.config, modifiez customErrors:

    

Si le mode est Off ou RemoteOnly, vous verrez alors l’écran jaune de la mort au lieu de la page d’erreur personnalisée. Le raisonnement est que les développeurs veulent généralement des informations plus détaillées sur l’écran jaune de la mort.

Important: veillez à ce que votre page d’erreur ne contienne pas d’erreur!

Si c’est le cas, vous vous retrouverez avec cette page d’erreur personnalisée ASP.NET et finirez par tourner en rond et arracher vos cheveux. Il suffit de supprimer tout ce qui pourrait éventuellement provoquer une erreur et le tester.

En outre, en ce qui concerne les “CustomErrors” étant activés ou désactivés, il existe plusieurs facteurs consortingbuant à l’affichage ou non de la page d’erreur conviviale (votre site Errors.aspx).

Voir ce blog (sauf ci-dessous)

HttpContext.IsCustomErrorEnabled – examine trois sources différentes

  1. La propriété retail de la section de web.config. C’est une propriété utile à définir lors du déploiement de votre application sur un serveur de production. Cela remplace tous les autres parameters pour les erreurs personnalisées.
  2. La propriété mode de la section de web.config. Ce paramètre indique si les erreurs personnalisées sont activées et si elles sont activées uniquement pour les demandes distantes.
  3. La propriété IsLocal de l’object HttpRequest. Si les erreurs personnalisées ne sont activées que pour les demandes distantes, vous devez savoir si la demande provient d’un ordinateur distant.

L’idée ici est que ‘customErrors’ peut être désactivé pendant le développement – lorsque vous souhaitez voir les erreurs, puis l’activer uniquement pour la production.

Cet article MSDN décrit l’atsortingbut plus loin.

Une autre raison de ce problème peut être,

Dans l’application MVC de modèle (générée par VS2008 / VS2008 Express), Error.aspx (généré par VS) utilise la page maître.

Si la page maître accède à n’importe quelle ViewData, elle lancera une exception de référence nulle, alors l’erreur.aspx ne sera pas affichée.

Utilisez ce code simple comme Error.aspx, cela résoudra le problème, (avec CustomErrors = On)

 <%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %> <%= Model.Exception.Message %> 

J’ai aussi eu du mal avec cela et je crois comprendre le problème maintenant.

En résumé, les conditions requirejses pour que [HandleError] fonctionne comme prévu sont les suivantes:

Vous devez activer les erreurs personnalisées dans web.config ET vous devez également spécifier l’emplacement de votre vue d’erreur dans la .

Exemple:

  

Si vous defaultRedirect="Error" la partie defaultRedirect="Error" obtiendrez une erreur 500 dans le navigateur – PAS la page d’erreur ASP.NET (YSOD).

De plus, vous ne devez pas être en mode Libération. Je l’ai testé avec une version Debug et cela a bien fonctionné.

Mon environnement était Visual Studio 2010 en utilisant .NET 4 et le modèle de projet standard “Application Web ASP.NET MVC 2”.

Ce qui m’a déconcerté, c’est la documentation MSDN pour la classe HandleErrorAtsortingbute. Il ne dit pas explicitement que vous devez activer les erreurs personnalisées dans web.config . Et j’ai supposé que tout ce dont j’avais besoin était l’atsortingbut [Handle Error] .

Il y a une situation idiote qui s’est déjà produite avec moi, alors ça pourrait être utile pour quelqu’un.

Assurez-vous d’avoir ajouté au fichier web.config correct .


Parfois (en particulier lorsque vous travaillez avec quelque chose comme Resharper et que vous ouvrez vos fichiers en tapant leur nom, mais pas via l’Explorateur de solutions), vous pouvez simplement ouvrir un fichier web.config à partir du dossier Views ou même d’un autre projet.

Attention: dans mon cas, je tentais d obtenir l atsortingbut HandleError pour intercepter une exception lancée à l intérieur du constructeur du Controller ! Bien sûr, il ne va pas l’attraper. L’atsortingbut HandleError ne capture que les exceptions lancées dans Controller actions du Controller . C’est juste là sur la page MSDN (aurait dû faire plus attention à cela):

Représente un atsortingbut utilisé pour gérer une exception déclenchée par une méthode d’action.

Une autre chose qui se produisait était que la OnException(ExceptionContext exceptionContext) du contrôleur n’était jamais appelée. Encore une fois: bien sûr, il ne serait pas appelé car je lançais une exception dans le constructeur du Controller .

J’ai passé une heure à essayer de comprendre cela. : o) J’espère que ça aide la prochaine âme …

À titre d’information, rappelez-vous que l’atsortingbut HandleError ne capture que 500 erreurs. Pour les autres, vous devez déclarer la section dans Web.config :