re: concepção de exceções personalizadas: I deve implementar o construtor padrão? o construtor “interior exceção”?

Question

A resposta para O que é a maneira correta de fazer exceções serializável? diz que a implementação base "correta" para uma exceção personalizada inclui 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)
    {
    }
}

Logo de cara, eu diria que é um nome muito ruim para um tipo de exceção. Mas, além disso,

1. Para fins de serialização binária, que é o que a pergunta SO estava se referindo, deve I implementar todos os 4 construtores ? Eu acho que para fins de [Serializable], I deve fornecer um ctor que aceita 2 argumentos do tipo (SerializationInfo, StreamingContext), porque os deriva de exceção de System.Exception, que se faz serialização personalizada. Eu posso entender isso. Mas devo implementar os outros ctors, , a fim de fornecer adequadamente uma exceção de serializado ? Eu sei que se eu quiser permitir que um tipo a ser xml serializável, eu preciso para fornecer o ctor padrão (não-op). É o mesmo verdadeiro para [Serializable]? Por um momento, vamos nos limitar à preocupação estreita de [Serializable], e deixar de lado quaisquer diretrizes mais amplas a respeito de "design de quadro".

2. Mover-se para a questão mais ampla: As diretrizes dizem que exceções personalizadas devem implementar os 4 ctors comuns . Qual é o raciocínio por trás dessa diretriz? Se eu criar uma exceção personalizada, é maneiras muito ruins, ou mesmo um erro, se eu não fornecer uma ctor nulo / default? É maneiras muito ruins, ou mesmo um erro, se eu não fornecer uma ctor que permite que um innerException? Por quê? Considere o caso de que minha exceção personalizada é gerada dentro do meu código da biblioteca, e os únicos exemplos que eu sempre jogar incluir uma mensagem, e não innerException.

3. Em suma, é o seguinte código aceitável para uma exceção personalizada que não fornece propriedades adicionais?

---

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

ver também: Winterdom blog:. Exceções Faça Serializable

Answer 1

Eu não gostava de nenhuma das respostas. Estou se decidir sobre a minha solução proposta, que é .. que eu possa eliminar os construtores "normais" no meu exceção personalizada, incluindo o construtor padrão e o construtor aninhada. Além disso, eu preciso certificar-se de obras de serialização, por causa de chamadas cross-AppDomain.

Answer 2

O aviso de análise de código relevante é CA1032, eo href="http://msdn.microsoft.com/en-us/library/ms182151.aspx" rel="nofollow página de referência fornece essa justificativa:

A falha em fornecer o conjunto completo de construtores podem tornar difícil tratar corretamente exceções. Para exemplo, o construtor, com a assinatura NewException (string, Exception) é usado para criar exceções que são causados ??por outra exceções. Sem esse construtor, você não pode criar e lançar uma instância de sua exceção personalizada que contém uma excepção interior (aninhado), que é o que o código gerenciado deve fazer em tal situação a. Os três primeiros construtores de exceção são públicos por convenção. O quarto é construtor protegido nas classes não seladas, e privado nas classes selados.

Somente você ou sua equipe de projeto pode decidir se seus situação merece uma exceção (sorry ...)

Answer 3

Ei, eu sei que é, pelo menos, aconselhado por Microsoft. Se você usar VS2008 (ou talvez versões anteriores), você pode facilmente deixar Visual Studio criá-los para você digitando

exception

no editor e pressionando Tab (duas vezes?). Isto irá criá-los, dando-lhe a chance de dar a classe um novo nome.

Answer 4

Sugestão: se os outros vão estar usando sua exceção, e uma vez que estes outros vão estar familiarizado com exceções .NET, então porque não basta seguir as orientações? Eles são os mesmos que são usados ??pelo .NET Framework.

Você está se sentindo isso é muito trabalho, dado o número de tipos de exceção personalizadas que você está definindo? Se assim for, então isso seria mais um motivo para seguir as orientações, que especificam que você não deve criar um grande número de exceções personalizadas.