re: conception des exceptions personnalisées: dois-je mettre en œuvre le constructeur par défaut? le constructeur « d'exception interne »?

Question

La réponse à Quelle est la bonne façon de faire des exceptions sérialisable? dit que la mise en œuvre de base « correcte » pour une exception personnalisée comprend 4 ctors:

[Serializable]
public class SerializableExceptionWithoutCustomProperties : Exception
{
    public SerializableExceptionWithoutCustomProperties()
    {
    }

    public SerializableExceptionWithoutCustomProperties(string message) 
        : base(message)
    {
    }

    public SerializableExceptionWithoutCustomProperties(string message, Exception innerException) 
        : base(message, innerException)
    {
    }

    // Without this constructor, deserialization will fail
    protected SerializableExceptionWithoutCustomProperties(SerializationInfo info, StreamingContext context) 
        : base(info, context)
    {
    }
}

Dès le départ, je dirais que c'est un nom vraiment mauvais pour un type d'exception. Mais, au-delà,

1. Pour la sérialisation binaire, qui est ce que la question SO faisait référence, dois-je mettre en œuvre tous les 4 constructeurs ? Je pense à des fins de [Serializable], je dois fournir un cteur qui accepte 2 args de type (SerializationInfo, StreamingContext), parce que l'exception dérive de System.Exception, qui lui-même ne sérialisation personnalisé. Je peux comprendre cela. Mais dois-je mettre en œuvre les autres cteurs, afin de fournir correctement une exception sérialisable ? Je sais que si je veux permettre à un type d'être xml sérialisable, je dois fournir la valeur par défaut (no-op) cteur. Est-ce la même chose pour [Serializable]? Pour un instant, nous allons nous en tenir à la préoccupation étroite de [Serializable], et laisser de côté les lignes directrices plus larges concernant « la conception du cadre ».

2. Passant à la question plus large: Les directives disent que exceptions personnalisées devraient mettre en œuvre les 4 cteurs communs . Quel est le raisonnement derrière cette ligne directrice? Si je crée une exception personnalisée, est-il vraiment mauvais manières, ou même un bug, si je ne fournis pas cteur null / default? Est-ce vraiment mauvais manières, ou même un bug, si je ne fournis pas un cteur qui permet à un innerException? Pourquoi? Prenons le cas que mon exception personnalisée est générée dans mon code de la bibliothèque, et les seuls cas que j'ai jamais jeter comprennent un message, et pas innerException.

3. En bref, est le code suivant acceptable pour une exception personnalisée qui ne fournit pas d'autres propriétés?

---

[Serializable]
public class CustomException : Exception
{
    public CustomException(string message) : base(message) { }

    // Without this constructor, deserialization will fail
    protected CustomException(SerializationInfo info, StreamingContext context) 
        : base(info, context) { }
}

voir aussi: Winterdom blog:. Faire des exceptions Serializable

Answer 1

Je n'ai pas aimé aucune des réponses. J'installer sur ma solution proposée, qui est .. que je peux éliminer les constructeurs « normaux » à mon exception personnalisée, y compris le constructeur par défaut et le constructeur imbriqué. , Je dois aussi faire des travaux de sérialisation sûr, parce que des appels entre domaines d'application.

Answer 2

L'avertissement code pertinent analyse est CA1032, et la page de référence fournit cette justification:

  

Le défaut de fournir l'ensemble des   les constructeurs peuvent rendre difficile à   gérer correctement les exceptions. Pour   par exemple, le constructeur avec la   NewException signature (chaîne,   Exception) est utilisé pour créer   exceptions qui sont causées par d'autres   exceptions. Sans ce constructeur,   vous ne pouvez pas créer et lancer une   instance de votre exception personnalisée   contient une exception interne (imbriqué),   qui est ce que le code managé devrait faire   Dans une telle situation. Les trois premiers   constructeurs d'exception sont publiques par   convention. Le quatrième constructeur est   protégées dans les classes non scellées, et   privé dans les classes scellées.

Seulement vous ou votre équipe de projet peut décider si votre situation justifie une exception (désolé ...)

Answer 3

Hé, je sais qu'il est au moins conseillé par Microsoft. Si vous utilisez VS2008 (ou peut-être des versions antérieures), vous pouvez facilement laisser Visual Studio les créer pour vous en tapant

exception

dans l'éditeur et en appuyant sur Tab (deux fois?). Cela les créer, vous donnant la chance de donner à la classe un nouveau nom.

Answer 4

Suggestion: si les autres vont utiliser votre exception, et que ces autres seront familiers avec les exceptions .NET, alors pourquoi ne pas suivre les directives juste? Ce sont les mêmes qui sont utilisés par le .NET Framework.

Vous sentez-vous ce trop de travail, compte tenu du nombre de types d'exception personnalisés que vous définissez? Si oui, alors ce serait une autre raison de suivre les directives, qui précisent que vous ne devriez pas créer un grand nombre d'exceptions personnalisées.