Discussion :

[Kaidan]

Bonjour,

Pour créer une custom exception, j'utilise la construction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class CustomException : Exception {
 
   public CustomException(string message) : base(message) {
      ...
   }
 
}

D'après ce que je comprends de ce code, le constructeur de Exception est exécuté avant le constructeur de CustomException (j'ai d'ailleurs vérifier que c'est bien le cas sur d'autres classes).

Dans mon constructeur, j'ai besoin d'accèder à TargetSite et à StackTrace. Mais ils sont tous les deux null ... même après l'exécution donc du constructeur de Exception. Par contre, ils sont bien renseignés si je les utilises plus tard dans le code (dans le catch par exemple). Est-ce normal ? Comment faire pour avoir accès à ces informations dans le constructeur de l'exception dérivée ?

Merci.

[StormimOn]

Dans mon constructeur, j'ai besoin d'accèder à TargetSite et à StackTrace. Mais ils sont tous les deux null ...

Ces informations ne seront disponibles que lorsque l'exception sera levée (avec le mot clé throw). Donc tu ne pourras jamais y avoir accès dans le constructeur.

La seule possibilité c'est de faire quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
try
{
    ...
}
catch(Exception ex)
{
    throw new CustomException(ex)
}

c'est à dire que l'on passe l'exception de départ (inner exception) au constructeur de la nouvelle exception. Mais ça alourdit l'ensemble, sans parler que tu changes la sémantique de l'exception au passage.

Pourquoi as-tu besoin de ces informations ?

[Kaidan]

Je voulais calculer automatiquement le message de l'exception au lieu de l'écrire en dur dans chaque levée d'exception (le message ayant le nom complet de la méthode (Namespace.Classe.Méthode) et le type d'erreur qui pourra ensuite être localisé).

Le but était de factoriser le code : si dans chaque méthode, je suis obligé de catcher ma CustomException pour en lever une autre avec le bon message, c'est pas la peine.

Je change déjà la sémantique de toutes les exceptions (l'exécution ne devrait retourner que des CustomException avec en InnerException l'exception de base).

Par contre, je pourrais écrire une méthode d'extension pour le faire finalement.

[StormimOn]

Le message associé à l'exception doit indiquer le problème rencontré et non l'endroit où il a eu lieu. Pour ça on utilise justement la pile des appels et la méthode à l'origine de l'exception (StackTrace et TargetSite).

Si tu affiches l'erreur dans une fenêtre, ce que tu peux faire c'est afficher le détail de l'exception si besoin (à la base on affiche juste le message, et un bouton permet d'afficher le détail avec la pile des appels par exemple).

Sinon tu peux faire une méthode statique qui prend une exception (qui aura été levée précédemment) en paramètre et te retourne une chaîne formatée avec le message de l'exception et la pile des appels / méthode à l'origine.

[Kaidan]

L'endroit ne m'intéresse pas vraiment en fait. C'était juste un moyen d'obtenir facilement une clé unique pour la localisation de chaque message d'exception. J'ai surchargé la propriété Message.get pour retourner une chaîne localisée à partir de cette clé, chaîne qui contient justement le message clair de l'exception en fonction de la culture.

[Kaidan]

Comme je surcharge Message.get, je peux directement vérifier TargetSite et retourner le bon message localisé sans passer par une méthode d'extension.