una - C#- ¿Por qué implementar constructores de excepción estándar?

utilice la palabra new para crear una instancia de objeto c#

Question

Desde MSDN, advertencia de análisis de código CA1032:

Exception types must implement the following constructors:

• public NewException()
• public NewException(string)
• public NewException(string, Exception)
• protected or private NewException(SerializationInfo, StreamingContext)

Entiendo el propósito detrás del constructor de serialización, pero ¿el razonamiento detrás de "requerir" a los demás? ¿Por qué no debería simplemente definir lo que los constructores tengan sentido para el uso de mi excepción? ¿Qué sucede si nunca deseo lanzar MyException sin pasar un mensaje? ¿Por qué debo definir un constructor sin parámetros? ¿Qué sucede si deseo que MyException tenga una propiedad int y solo quiero constructores que inicialicen esa propiedad?

Answer 1

Bueno, el constructor que toma una excepción interna es bastante necesario para hacer una excepción personalizada apropiadamente utilizable. Sin él, si alguien atrapó su excepción, no podrían disparar una excepción más descriptiva o apropiada a la vez que conservan la original (y la información que contiene, como el seguimiento de la pila).

Answer 2

Esto es una advertencia, no un requisito. Básicamente es el principio de la menor sorpresa . Proporcionar los 4 hace que sea más fácil para las personas acostumbradas a las excepciones de C # "regulares" usar el suyo. Si tiene una buena razón para ignorar la guía, hágalo. Pero romperá ciertos escenarios de uso y hará que su clase sea un poco menos intuitiva.

Answer 3

Has obtenido algunas buenas respuestas. Solo quiero agregar que proporcionar estos constructores adicionales no requiere necesariamente mucha codificación. Ya que ya están implementados en la clase base, simplemente puede dejar que uno haga el trabajo:

public class MyCustomException : Exception
{
public MyCustomException() : base() { }
public MyCustomException(string message) : base(message) { }
public MyCustomException(string message, Exception innerException) : base(message, innerException) { }
// and so on...
}

Por lo tanto, solo necesitará implementar un código en el que el comportamiento de su excepción se desvíe del de la clase base.

Answer 4

La implementación de los constructores de excepciones estándar permite a las personas utilizar su excepción de una manera estándar y familiar que está integrada en todas las excepciones existentes de .NET. Los primeros tres pueden ser opcionales, si por alguna razón no quieres que se use uno de ellos (aunque por qué querrías que no pudiera entenderlo). Sin embargo, el último es el constructor de deserialización, y si lo deseas Su excepción es compatible con cualquier tipo de entorno distribuido (.NET Remoting, ASP.NET Web Services, WCF, etc.), por lo que es bastante esencial.

Sin un constructor de deserialización y el atributo [Serializable], sus excepciones no funcionarán en un entorno distribuido y podrían causar otros problemas. Dado eso, y el aspecto de familiaridad con los desarrolladores de C # bien versados, es mejor implementar al menos los 4 constructores de excepciones estándar y marcar sus excepciones con [Serializable].

Answer 5

Los constructores sin parámetros y de serialización son utilizados por el código genérico de "enrutamiento de excepciones" que necesita mover las excepciones entre dominios (por ejemplo, a través de Internet entre un servicio y un cliente).

El que toma otra Exception es para que sea posible encadenar todas las excepciones a través de la propiedad InnerException .

Finalmente, está el que toma una cadena de mensaje, que ayuda a hacer uso de excepciones razonablemente consistentes.