Re: progettazione di eccezioni personalizzate: devo implementare il costruttore di default? la “eccezione interna” costruttore?

Question

La risposta a Qual è il modo corretto di fare eccezioni serializzabile? dice che l'implementazione di base "corretto" per un eccezione personalizzata comprende 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)
    {
    }
}

Destra fuori del blocco, direi che è un nome davvero male per un tipo di eccezione. Ma, oltre a questo,

1. Ai fini della serializzazione binario, che è ciò che il SO domanda si riferiva a, devo implementare tutti e 4 i costruttori ? Credo che ai fini della [Serializable], devo fornire un ctor che accetta 2 argomenti di tipo (SerializationInfo, StreamingContext), perché l'eccezione deriva da System.Exception, che a sua volta fa serializzazione personalizzata. Posso capire che. Ma devo attuare le altre ctors, al fine di fornire correttamente un'eccezione serializzabile ? So che se voglio permettere un tipo di essere xml-serializzabile, ho bisogno di fornire il (no-op) ctor di default. È lo stesso vale per [Serializable]? Per un momento, cerchiamo di limitarci alla stretta preoccupazione di [Serializable], e lasciare da parte delle linee guida più generali in materia di "progettazione quadro".

2. Lo spostamento verso la questione più ampia: Le linee guida dicono che em <> eccezioni personalizzate dovrebbero implementare i 4 ctors comuni . Qual è il ragionamento che sta dietro questa linea guida? Se disegno un'eccezione personalizzata, è davvero cattive maniere, o anche un bug, se non fornisco un null / ctor di default? E 'davvero cattive maniere, o anche un bug, se non fornisco un ctor che permette un'innerException? Perché? Si consideri il caso che la mia eccezione personalizzato viene generato all'interno del mio codice della libreria, e gli unici casi che io abbia mai butto includono un messaggio, e non innerException.

3. In breve, è il seguente codice accettabile per un'eccezione personalizzata che fornisce immobili supplementari?

---

[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) { }
}

vedi anche: Winterdom blog:. Fare eccezioni Serializable

Answer 1

non mi piaceva nessuna delle risposte. Sto stabilirsi su mia soluzione proposta, che è .. che posso eliminare i "normali" costruttori sul mio eccezione personalizzata, tra cui il costruttore di default e il costruttore nidificato. Inoltre, ho bisogno di fare certi lavori di serializzazione, a causa delle chiamate tra AppDomain.

Answer 2

Il relativo avviso di analisi del codice è CA1032, e il href="http://msdn.microsoft.com/en-us/library/ms182151.aspx" rel="nofollow di riferimento fornisce questa giustificazione:

  

Il mancato conferimento la serie completa di   i costruttori possono rendere difficile   correttamente gestire le eccezioni. Per   esempio, il costruttore con il   firma NewException (stringa,   Exception) viene utilizzato per creare   eccezioni che sono causati da altri   eccezioni. Senza questo costruttore,   Non è possibile creare e lanciare un   istanza del eccezione personalizzata che   contiene un'eccezione interna (nested),   che è ciò che il codice gestito dovrebbe fare   in una situazione del genere. I primi tre   costruttori di eccezione sono pubblici   convenzione. Il quarto costruttore è   protetta nelle classi non sigillati, e   privato nelle classi sigillate.

Solo voi o il vostro team di progetto può decidere se la vostra situazione giustifica un'eccezione (scusate ...)

Answer 3

Hey, lo so che è almeno consigliato da Microsoft. Se si utilizza VS2008 (o forse le versioni precedenti) si può facilmente lasciare Visual Studio li crea per voi digitando

exception

nell'editor e premendo Tab (due volte?). Questo creerà loro, dandovi la possibilità di dare un nuovo nome alla classe.

Answer 4

Suggerimento: se gli altri useranno il vostro eccezioni, e dal momento che questi altri avranno familiarità con le eccezioni .NET, allora perché non basta seguire le linee guida? Sono gli stessi che vengono utilizzati da .NET Framework.

Ti senti questo è troppo lavoro, dato il numero di tipi di eccezione personalizzati che si sta definendo? Se è così, allora questo sarebbe un altro motivo per seguire le linee guida, che specificano che non si deve creare un gran numero di eccezioni personalizzate.