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

StackOverflow https://stackoverflow.com/questions/408480

Pregunta

Desde que Microsoft introdujo los bloques de aplicaciones, me he topado con personas que usan Bloqueo de aplicaciones de gestión de excepciones . Recientemente, me examiné con más detenimiento y resumiría la funcionalidad básica de la siguiente manera (omita el siguiente bloque si ya sabe lo que hace):

  

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

     
      
  • Registro de una excepción
    •   
  • Sustitución de una excepción
    •   
  • Envolver una excepción
    •   
  • Propagar una excepción
    •   
  • etc.
    •   
     

La biblioteca lo hace modificando los bloques de captura de prueba 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 el archivo app.config para el nombre de la política ( ver aquí para documentos ), HandleException será ...

     
      
  • lanzar una excepción completamente nueva (reemplazar la excepción original)
    •   
  • envuelve la excepción original en una nueva y lanza esa
    •   
  • 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).

Este es mi problema: no veo por completo cómo puede ser beneficioso hacerlo configurable si una excepción se reemplaza, se ajusta, se traga o se vuelve a derribar. En mi experiencia, esta decisión debe tomarse en el momento en que escribe el código porque, por lo general, tendrá que cambiar el código circundante o el código de llamada cuando cambie el comportamiento de manejo de excepciones.

Por ejemplo, es probable que su código comience a comportarse de manera incorrecta cuando se reconfigure de tal manera que ahora se trague una excepción en particular en un punto en particular en lugar de volver a destruirla (puede haber un código después del bloque catch que no debe ejecutarse cuando la excepción ocurre). Lo mismo ocurre con todos los demás cambios posibles en el manejo de excepciones (por ejemplo, reemplazar - > rethrow, swallow - > wrap).

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 bit de registro y notificación de excepciones está bien, pero ¿no son todas las otras cosas solo un ejemplo perfecto para la ingeniería excesiva?

¿Fue útil?

Solución

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

Pero en el caso de las 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 basado en políticas. .

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

Ese algo debería ser configurable, porque realmente no importa lo que hagas. ¿Mostrar un cuadro de mensaje al usuario? ¿Modal o no modal? ¿Registrar la excepción? ¿Cómo quieres registrar la excepción? ¿Llamar a un servicio web de registro? ¿Adjuntar 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 le importa al resto de su aplicación. La elección de cómo manejar una excepción es completamente ortogonal al resto de la aplicación.

(Dejando de lado, no es así como abordaría el manejo de excepciones basado en políticas configurables. Tendría más tendencia a un estilo AOP, como registrar un interceptor de registrador de excepciones en el contenedor).

Otros consejos

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 asegura que todos los demás desarrolladores que forman parte de este proyecto realmente cumplan con 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.

Estoy 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 bloqueo desde su lanzamiento y rara vez siento que realmente estoy ganando mucho con su uso. Bueno, tal vez un poco de dolor de cabeza. :)

Antes de comenzar, admitiré que me gusta el Protección contra excepciones en WCF Funcionalidad de límites de servicio . Sin embargo, esto se agregó recientemente, no implica la codificación, solo atributos y configuración, y no es la forma en que se vende el bloque. Así es como Microsoft lo muestra en http://msdn.microsoft.com/en -us / library / cc309250.aspx

texto alternativo

Para mis ojos, 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 es haciendo que el código parezca incorrecto mal . (No importa que la construcción if (rethrow) no ofrezca mucha abstracción). Esto puede hacer que el mantenimiento sea más difícil para los desarrolladores que no están familiarizados con las definiciones de políticas. Si se modifica el postHandlingAction en el archivo de configuración (probablemente sucederá en algún momento), es probable que la aplicación se comporte de forma inesperada y que nunca se haya probado.

Tal vez no me parecería objetable si el bloque no controlara el control de flujo, sino que simplemente permitiera que los manejadores de cadenas se unieran.

Pero tal vez no. En realidad no recuerdo haber sido invitado a:

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

No estoy diciendo que no suceda (estoy seguro de que alguien tiene una historia); Simplemente siento que el Bloqueo de aplicaciones de manejo de excepciones hace que los programas sean más difíciles de entender y mantener, y esto generalmente supera la funcionalidad proporcionada por el bloque.

No creo que esto sea sobre ingeniería en absoluto. de hecho. El hecho de que las excepciones puedan pasar a través de un controlador central ha sido algo bueno en mi línea de trabajo. He tenido desarrolladores que comían todas las excepciones, manejadas o no, de modo que no se dispararan hasta la parte superior y pusieran algo alarmante frente al usuario final o estropearan seriamente un servicio / demonio cuando no se detectan.

ahora con la política podemos iniciar el registro en cualquier momento sin tener que reiniciar o esparcir innecesariamente la lógica de registro en toda la aplicación. ahora podemos ver las excepciones y demás sin tener que desconectar la aplicación.

programación inteligente si me preguntas ...

En pocas palabras: si desea un manejo de excepciones diferente en su código de versión que en su código de depuración, sería útil.

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

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

Una línea de código: ¿qué tan simple puedes conseguir? 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 sin tener que volver a compilar el código fuente.

Como se mencionó, la política de excepciones puede realizar muchas acciones, cualquiera que sea la definición de su política. Ocultando la complejidad detrás de una línea de código como se muestra dentro del bloque catch, es donde veo un valor real.

Yo diría que es complejo, pero no con una ingeniería excesiva. Por lo tanto, 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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top