Exception.Data info est manquante dans le journal EntLib

Question

Comment obtenir le bloc d'application de gestion des exceptions (EHAB) pour écrire les valeurs de la propriété Exception.Data dans le journal?

try 
    { 
    // ... 
    } 
    catch (Exception ex) 
    { 
    ex.Data.Add("Hello", "World"); 
    throw ex; 
    } 

L'exception est enregistré correctement, mais je ne peux pas trouver les données ajoutées partout dans l'entrée du journal créé par EHAB. Pour autant que je sache, il est recommandé d'ajouter des informations pertinentes à l'exception elle-même, comme dans l'exemple ci-dessus. C'est pourquoi je suis un peu surpris qu'EHAB ne l'inclue pas par défaut. Puis-je résoudre ce problème en modifiant le modèle avec l'Éditeur de modèles EntLib Text Formatter (capture d'écran ci-dessous)? Je ne trouve aucune information sur les différents "jetons" fournis, mais je suppose que la réponse est cachée quelque part avec eux.

Text Formatter Template Editor http://img195.imageshack.us/img195/6614/capturegmg.png

Ou dois-je vraiment besoin de mettre en œuvre ma propre Formatter de texte personnalisé pour y parvenir?

EDIT/MISE À JOUR:

Je le fais dans mes Global.asax.cs afin d'éviter d'avoir à ajouter l'appel de méthode HandleException partout dans mon code:

using EntLib = Microsoft.Practices.EnterpriseLibrary; 
using System; 

namespace MyApp 
{ 
    public class Global : System.Web.HttpApplication 
    { 
    protected void Application_Error(object sender, EventArgs e) 
    { 
     // I have an "All Exceptions" policy in place... 
     EntLib.ExceptionHandling.ExceptionPolicy.HandleException(Server.GetLastError(), "All Exceptions"); 
     // I believe it's the GetLastError that's somehow returning a "lessor" exception 
    } 
    } 
} 

Il se trouve c'est pas le même que celui (qui fonctionne très bien, et résout essentiellement mon problème):

try 
{ 
    // ... 
} 
catch (Exception ex) 
{ 
    ex.Data.Add("Hello", "World"); 
    bool rethrow = ExceptionPolicy.HandleException(ex, "Log Only Policy"); 
    throw ex; 
} 

Passer en revue tout le code et ajouter des try-catch avec un appel HandleException semble juste ... bien, stupide. Je suppose que mon problème est vraiment comment utiliser correctement EHAB, pas de configuration.

Une suggestion sur la façon dont je peux correctement enregistrer toutes les exceptions sur un «niveau global» dans une application Web ASP.NET?

Answer 1

Vous ne devriez pas avoir à créer votre propre formateur.

Chaque élément de Data IDictionary sur l'objet Exception est ajouté au dictionnaire ExtendedProperties de l'objet LogEntry et enregistré (si spécifié par le formateur). Le fragment de propriétés {: {dictionary ({clé} - {valeur})} config doit contenir toutes les paires clé/valeur dans le dictionnaire des propriétés étendues. Si vous souhaitez enregistrer un seul élément de la collection, vous pouvez utiliser "keyvalue". Dans votre exemple, ce serait quelque chose le long des lignes de:

Hello Key: {keyvalue(Hello)} 

j'ai modifié le ExceptionHandlingWithLoggingQuickStart pour ajouter Data.Add (« Bonjour », « World ») et je vois « Propriétés étendues: Bonjour - World » à la fin de l'entrée du journal des événements. Donc ça marche.

Si vous ne voyez pas ce comportement, vous devez vous assurer:

• Que votre exception avec les éléments de données ajoutées est passée à ExceptionPolicy.HandleException
• Que la politique spécifiée dans la méthode HandleException est configuré pour se connecter avec un LoggingExceptionHandler dans la configuration
• Que le formatter qui est spécifié dans le LoggingConfiguration est configuré pour supporter ExtendedProperties

Si vous le pouvez Ne voyez pas le problème, comparez ce que vous avez avec le QuickStart. Si cela ne fonctionne toujours pas, postez votre code et votre config.

MISE À JOUR:

Si vous allez gérer Application_Error dans le global.asax alors vous recevrez un HttpUnhandledException depuis la page ne gère pas l'erreur. Vous pouvez récupérer l'exception qui vous intéresse en utilisant la propriété InnerException; InnerException contiendra l'exception d'origine (sauf si elle est dans InnerException de cette exception :)). Alternativement, vous pouvez utiliser Server.GetLastError().GetBaseException() pour récupérer l'exception qui est la cause première.