¿Por qué debería siempre hacer mis Excepciones ? (.RED)

Refiriéndose a ¿Cuál es la forma correcta de hacer una excepción .NET personalizada serializable?
y ¿Se pueden serializar todas las excepciones de .NET? …

¿Por qué mis excepciones deben ser serializables?
Alguien dijo “se puede considerar un error” si una excepción personalizada definida por una biblioteca de terceros no es serializable. ¿Por qué?

¿Por qué las excepciones son diferentes a otras clases en este sentido?

Debido a que sus excepciones pueden necesitar ser ordenadas entre diferentes AppDomains y si no son (adecuadamente) serializables, perderá información valiosa de depuración. A diferencia de otras clases, no tendrá control sobre si su excepción se organizará, lo hará.


Cuando digo “no tendrás control” me refiero a que las clases que creas generalmente tienen un espacio finito de existencia y la existencia es bien conocida. Si se trata de un valor de retorno y alguien intenta llamarlo en un Dominio de aplicación diferente (o en una máquina diferente) obtendrá un error y puede decir “No lo use de esa manera”. La persona que llama sabe que tienen que convertirlo en un tipo que se puede serializar (envolviendo la llamada al método). Sin embargo, dado que las excepciones se borran hasta la parte superior si no se capturan, pueden trascender los límites de AppDomain que ni siquiera sabías que tenías. Su excepción de aplicación personalizada de 20 niveles de profundidad en un AppDomain diferente podría ser la excepción reportada en Main () y nada en el camino la convertirá en una excepción serializable para usted.

Además de la respuesta de Talljoe, sus excepciones pueden pasarse a través de los servicios web también, en este caso la excepción debe ser serializable / deserializable para que pueda ser convertida en XML y transmitida por el servicio web.

Creo que el valor predeterminado para todas las clases debería ser Serializable, a menos que contengan una clase que no se pueda serializar explícitamente. Es molesto no poder transferir una clase solo porque algún diseñador no lo pensó.

Lo mismo con “Final”, todas las variables deben ser “Finales” por defecto a menos que específicamente diga que son “Mutables”.

Además, no estoy seguro de que tenga sentido tener una variable que no sea privada.

Bueno, necesito diseñar mi propio idioma.

Pero la respuesta es que no sabe cómo se usará su excepción y se supone que puede lanzarse a través de llamadas remotas.

Otro lugar donde los objetos deben ser serializables es Asp.Net Session. Almacenamos la última excepción en la sesión y las excepciones no serializables necesitan una traducción adicional para almacenar sus detalles como serializables (especificar la excepción original como interno no ayuda)