.net - propiedades - tipos de excepciones en c#

Bloque de manejo de excepciones de Microsoft: ¿no es un ejemplo perfecto para la sobreingeniería?

Question

Desde que Microsoft presentó los bloques de aplicaciones, me he topado con personas que usan el Bloque de aplicaciones de manejo de excepciones . Recientemente, he tenido una mirada más cercana y resumiría la funcionalidad básica de la siguiente manera (omita el siguiente bloque si ya sabe lo que hace):

El bloque de aplicación de manejo de excepciones tiene como objetivo centralizar y hacer totalmente configurables con archivos de configuración las siguientes tareas clave de manejo de excepciones :

• Registrando una excepción
• Reemplazar una excepción
• Envolver una excepción
• Propagando una excepción
• etc.

La biblioteca lo hace haciendo que modifiques tus bloques try catch de la siguiente manera:

try
{
// Run code.
}
catch(DataAccessException ex)
{
bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
if (rethrow)
{
throw;
}
}

En función de lo que se especifica en la aplicación.config para el nombre de la política ( ver aquí para los documentos ), HandleException o bien ...

• lanzar una excepción completamente nueva (reemplace la excepción original)
• envolver la excepción original en una nueva y lanzar eso
• tragar la excepción (es decir, no hacer nada)
• has vuelto a lanzar la excepción original

Además, también puede configurarlo para hacer más cosas de antemano (por ejemplo, registrar la excepción).

Ahora este es mi problema: no entiendo por completo cómo puede ser beneficioso hacer que sea configurable ya sea que se reemplace, envuelva, trague o recupere una excepción. En mi experiencia, esta decisión debe tomarse en el momento de escribir el código porque, por lo general, tendrá que cambiar el código circundante o de llamada cuando cambie el comportamiento de manejo de excepciones.

Por ejemplo, es probable que su código comience a comportarse incorrectamente cuando se reconfigura, de modo que una excepción particular lanzada en un punto particular se traga en lugar de volver a lanzarse (puede haber código después del bloque catch que no se debe ejecutar cuando se produce la excepción). Lo mismo ocurre con todos los demás cambios posibles en el manejo de excepciones (p. Ej., Reemplazar -> volver a tirar, tragar -> envolver).

Entonces, para mí, la conclusión es que el bloque de manejo de excepciones resuelve problemas que realmente no existen en la práctica. El registro de excepción y el bit de notificación están bien, pero ¿no es todo lo demás simplemente un ejemplo perfecto para la sobreingeniería?

Answer 1

En mi opinión, un valor real de usar el bloque Exception Handling comienza con una línea de código en tu bloque catch:

bool rethrow = ExceptionPolicy.HandleException (por ejemplo, "Política de acceso a datos");

Una línea de código: ¿qué tan simple puedes obtener? Detrás de una línea de código, la política, tal como está configurada, hace que la asignación / actualización de una política se lleve a cabo fácilmente, todo ello sin tener que volver a compilar el código fuente.

Como se mencionó, la política de excepción en realidad puede realizar muchas acciones, independientemente de lo que se defina en su política. Ocultar la complejidad detrás de una línea de código como se muestra dentro del bloque catch, es donde veo el valor real.

Yo diría complejo, pero no demasiado ingenioso. Así que mi opinión es que se verán grandes dividendos durante el mantenimiento cuando necesite cambiar la forma en que maneja / registra las excepciones al tener la flexibilidad de cambiar la configuración fácilmente y aún tener la misma línea de código fuente.

Answer 2

Me encuentro con este problema cuando estoy desarrollando funciones que no tienen un estado recuperable. Creo que este manejo de excepciones basado en políticas es realmente útil y garantiza que todos los demás desarrolladores que forman parte de este proyecto se adhieran realmente a un estándar para excepciones no recuperables.

Estoy de acuerdo con los carteles anteriores, es posible que desee mantenerse alejado de las excepciones basadas en políticas si las está utilizando para el flujo de control.

Answer 3

Muy simple: si desea un manejo de excepción diferente en su código de liberación que en su código de depuración, entonces sería útil.

Answer 4

No creo que esto termine con la ingeniería. de hecho. el hecho de que las excepciones puedan pasar a través de un controlador central ha sido algo bueno en mi trabajo. He tenido desarrolladores que comerían todas las excepciones, manejadas o no, de modo que no llegaran a la parte superior y pusieran algo alarmante frente al usuario final o estropearían gravemente un servicio / daemon cuando no se detectara.

ahora con la política podemos comenzar a iniciar sesión en cualquier momento sin tener que reiniciar o rociar innecesariamente la lógica de registro en toda la aplicación. ahora podemos ver excepciones y cosas similares sin tener que desconectar la aplicación.

programación inteligente si me preguntas ...

Answer 5

Si usa excepciones para el flujo de control, querrá mantenerse alejado del manejo de excepciones basado en políticas.

Pero en el caso de excepciones que desea tratar como no recuperables (una tarea en segundo plano falló, el socket se desconectó, el archivo se eliminó, etc.), es posible que desee un manejo de excepciones configurable y basado en políticas.

Por ejemplo, si está desarrollando una API, puede desear que cada función en su API arroje solo las excepciones estándar ( ArgumentException , etc.), así como su propia excepción específica de la biblioteca en el caso de una falla interna no estándar. excepción (por ejemplo, una MyLibraryException ). En este tipo de caso, todo lo que importa es que algo no funcionó correctamente. No está desglosando la excepción y averiguando qué salió mal. Simplemente está reconociendo el hecho de que algo salió mal, y que se supone que debe hacer algo ahora.

Que algo debe ser configurable, porque realmente no importa lo que hagas. Mostrar un cuadro de mensaje para el usuario? ¿Modal o no modal? Log la excepción? ¿Cómo desea registrar la excepción? ¿Llamar a un servicio web de registro? ¿Agregar a un archivo de registro? Escribir en el registro de eventos de Windows? Insertar una entrada en la base de datos? Insertar una entrada en dos bases de datos? Realmente no importa para el resto de su aplicación. La elección de cómo manejar una excepción es completamente ortogonal al resto de la aplicación.

(Por otro lado, no es así como abordaría el manejo de excepciones basado en políticas configurables. Tendría más tendencia hacia un estilo de AOP, como registrar un interceptor de registro de excepción en el contenedor).

Answer 6

Tengo que estar de acuerdo con la afirmación de que "el bloque de manejo de excepciones resuelve problemas que realmente no existen en la práctica". He usado el bloque desde su lanzamiento y rara vez siento que estoy ganando mucho al usarlo. Bueno, tal vez un poco de dolor de cabeza. :)

Antes de comenzar, admitiré que me gusta el Exception Shielding en la funcionalidad WCF Service Boundaries . Sin embargo, eso fue agregado bastante recientemente, no involucra codificación, solo atributos y configuración, y no es como el bloque generalmente se vende. Así es como Microsoft lo muestra en http://msdn.microsoft.com/en-us/library/cc309250.aspx

texto alternativo http://i.msdn.microsoft.com/Cc309250.05-CrossLayer(en-us,MSDN.10).gif

Para mí, lo anterior es control de flujo.

try
{
// Run code.
}
catch(DataAccessException ex)
{
bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
if (rethrow)
{
throw;
}
}

Cuando combina el aspecto de control de flujo con el código anterior, definitivamente no está haciendo que el código incorrecto se vea mal . (No importa que la construcción if (rethrow) no ofrezca mucha abstracción.) Esto puede dificultar el mantenimiento para desarrolladores que no están familiarizados con las definiciones de políticas. Si se postHandlingAction el postHandlingAction en el archivo de configuración (probablemente ocurrirá en algún momento), probablemente la aplicación se comporte de formas inesperadas que nunca se han probado.

Tal vez no me resultaría objetable si el bloque no manejara el control de flujo, sino que simplemente te permitiera encadenar a los manipuladores.

Pero tal vez no. Realmente no recuerdo que me pidieran:

• agregue una nueva funcionalidad cuando maneje una excepción (por ejemplo, además de iniciar sesión en el registro de eventos también envíe un correo electrónico. En realidad, el bloque de registro puede hacerlo por sí mismo si usted ya estaba registrando la excepción).
• cambie el comportamiento de manejo de excepciones (tragar, volver a lanzar o lanzar nuevo) a través de una "política" completa.

No estoy diciendo que no suceda (¡estoy seguro de que alguien tiene una historia!); Siento que el Bloque de aplicaciones para el manejo de excepciones dificulta la comprensión y el mantenimiento de los programas, y esto generalmente supera la funcionalidad provista por el bloque.