tipos - try catch c#

¿Están todas las excepciones de.NET serializables?

Question

¿Se pueden serializar todos los objetos de excepción .NET?

Answer 1

Sí, pero históricamente ha habido (sin intención de hacer) excepciones.

En otras palabras, todas las excepciones DEBEN ser serializables , pero algunas excepciones personalizadas de código de terceros pueden no serlo, dependiendo de cómo se implementen.

Por ejemplo, en la era de .NET 1.0, las excepciones del proveedor oficial de la base de datos Oracle de Oracle no eran serializables, debido a errores en su código.

Answer 2

System.Exception implementa ISerializable , pero es posible que los descendientes no se deserialicen si no implementan el constructor sobrecargado correcto con la firma (SerializationInfo,StreamingContext) .

Answer 3

System.Exception implementa ISerializable y es la clase base para todas las excepciones, por lo que sí.

Ver: http://msdn.microsoft.com/en-us/library/system.exception.aspx

Answer 4

Esta pregunta ya se ha respondido lo suficiente, pero para los programadores que son nuevos en C # o Serialización, creo que en realidad es muy útil señalar que, en general, ¡las Excepciones NO son serializables!

Eso puede sonar un poco provocativo, pero déjame explicarte.

Es cierto que todas las Excepciones implementan la interfaz ISerializable, pero esto solo sugiere que debe ser serializable. Pero la implementación de la interfaz NO hace que un objeto sea serializable (lo que en este contexto implica que la excepción se puede serializar y deserializar).

La respuesta más precisa a esta pregunta, como han señalado otros, es que muchas pero no todas las excepciones en .Net Framework son serializables. Pero si la pregunta es usar el término ".Net Exception" en un ámbito más amplio, por ejemplo, una Excepción derivada de System.Exception, entonces la mejor y más útil respuesta, en términos de mejores prácticas y evitar errores, es la afirmación que hice anteriormente , que en general las Excepciones no son Serializables.

He aquí el por qué: Como se dijo anteriormente, para que una Excepción sea verdaderamente serializable, debe tener el constructor apropiado ctor(SerializationInfo, StreamingContext) y debe estar decorado con el atributo apropiado. Es importante destacar que ninguna de estas restricciones causa errores en el compilador si se omiten.

Lo que esto significa es que NO clase derivada de Excepción es Serializable a menos que se tomen estos pasos adicionales, opcionales (desde la perspectiva del compilador).

Es decir, cualquier codificador no graduado / inconsciente que derive una nueva excepción como la que se muestra a continuación acaba de crear una excepción que NO sea serializable.

class MyNewException : Exception { }

Visual Studio tiene un gran fragmento de "Excepción" que te permite generar nuevas excepciones serializables bastante rápido. Pero incluso en este caso, no hay nada que recordar o ayudar al programador a serializar realmente las propiedades del objeto. Por ejemplo, incluso si la clase siguiente tuviera el constructor y el atributo apropiados, la propiedad MyNewField no se serializaría sin código adicional tanto en el constructor como en GetObjectData.

class MyNewException : Exception 
{
    public MyNewField { get; set; }
}

Entonces, el punto principal aquí es que si debe confiar en la serialización y deserialización de excepción adecuada por alguna razón, debe ser completamente consciente de que cuando se trata de cualquier ensamblado o código personalizado, no hay garantía de que funcione. Además, dado que el constructor requerido generalmente está protegido, no necesariamente podrá verificar fácilmente que esté presente (sin reflejo).

En mis propios proyectos, he creado en algunos puntos "Proxies" de excepción que pueden almacenar parte de la información (por ejemplo, mensajes, etc.) de excepciones que no son serializables. Se pueden usar para serializar parte de la información, o alternativamente para deserializar datos escritos por una Excepción que no tiene el constructor apropiado.

Answer 5

Si y no. Como Jeff y otros han señalado, todas las clases de excepción deben ser, y casi siempre, serializables. Si te encuentras con una clase de excepción particular que no es serializable, posiblemente sea un error.

Pero al considerar la serializabilidad, debe considerar tanto la clase inmediata como todos los tipos que son miembros de este tipo (este es un proceso recursivo). La clase de excepción base tiene una propiedad de datos que es de tipo IDictionary. Esto es problemático porque le permite a usted, o a cualquier otra persona, agregar cualquier objeto en la Excepción. Si este objeto no es serializable, la serialización de la excepción fallará.

La implementación predeterminada de la propiedad Data hace una comprobación básica para garantizar que un objeto que se está agregando sea serializable. Pero es defectuoso de varias maneras

• Solo hace una verificación de nivel superior para la serialización de un tipo y esta verificación solo se realiza al marcar Type.IsSerializable (no es una verificación 100% sólida).
• La propiedad es virtual. Un tipo de excepción derivada podría anular y usar una Hashtable que hace 0 comprobación.