¿Cómo implementar el manejo de excepciones de nivel superior?

Question

Hace poco tuve que desarrollar un módulo adicional para un servicio existente desarrollado por un colega. Había colocado un bloque try / catch en la función de trabajo principal para detectar todas las excepciones no administradas que se acumulaban en este nivel, registrándolas con información de seguimiento de la pila, etc.:

try
{
    // do main work
}
catch(Exception ex)
{
    // log exception info
}

Aunque esto hace que el programa sea muy estable (como en 'improbable que se bloquee'), lo odio porque cuando estoy probando mi código, no veo las excepciones causadas por él. Por supuesto, puedo ver el registro de excepciones y ver si hay nuevas entradas, pero prefiero la retroalimentación directa para obtener la excepción en el momento en que se produce (con el cursor en la línea derecha en el código, por favor). / p>

Eliminé este nivel superior de prueba / captura al menos mientras aún estaba programando y probando. Pero ahora mi tarea está terminada y tengo que decidir si volver a ponerla para el lanzamiento o no. Creo que debería hacerlo, porque hace que el servicio sea más estable, y todo el asunto es que se ejecuta en segundo plano sin necesidad de supervisión. Por otro lado, he leído que solo se deben llamar excepciones específicas (como en IoException ), no genéricamente Exception .

¿Cuál es su consejo sobre este tema?

Por cierto, el proyecto está escrito en C #, pero también estoy interesado en las respuestas para los idiomas que no son .NET.

Answer 1

Ponlo de vuelta.

La excepción solo debe ser relevante durante la prueba. De lo contrario no tiene sentido pop para el usuario.

El registro está bien.

También puede usar el símbolo DEBUG definido por Visual Studio para las construcciones de depuración como una bandera.

    ...
    } catch( Exception e ) { 
#if DEBUG
          throw;
#else
          log as usual 
#endif
    }

Por lo tanto, la próxima vez que se necesite una modificación, el indicador de depuración se debe establecer en verdadero y aparecerá la excepción.

Answer 2

En cualquier aplicación Java, siempre querrás definir un controlador de excepciones para las excepciones no detectadas con algo como esto:

Thread.setDefaultUncaughtExceptionHandler( ... );

donde el objeto que detectará estas excepciones no detectadas al menos registrará el error para que tenga la oportunidad de saberlo. De lo contrario, no hay garantía de que se le notifique que un subproceso recibió una excepción, a menos que sea su subproceso principal.

Además de hacer esto, la mayoría de mis hilos tienen un try / catch donde capturaré RunnableException (pero no Error ) y los registraré ... algunos Los hilos se apagarán cuando esto suceda, otros registrarán e ignorarán, otros mostrarán una queja al usuario y dejarán que el usuario decida, dependiendo de las necesidades de la Aplicación. Este try / catch se encuentra en la raíz del subproceso, en el método Runnable.run () o equivalente. Dado que el try / catch se encuentra en la raíz del subproceso, no es necesario deshabilitar esta captura a veces.

Cuando escribo en C #, codifico de manera similar. Pero todo esto depende de la necesidad de la aplicación. ¿Es la excepción la que corromperá los datos? Pues bien, no lo atrapes y lo ignores. SIEMPRE regístrelo, pero luego deje que la aplicación muera. Sin embargo, la mayoría de las excepciones no son de este tipo.

Answer 3

Lo ideal es que manejes una excepción lo más cerca posible de lo que ocurrió, pero eso no significa que un controlador de excepciones global sea una mala idea. Especialmente para un servicio que debe seguir funcionando a toda costa. Yo continuaría lo que has estado haciendo. Desactívelo mientras realiza la depuración, pero déjelo en su lugar para la producción.

Tenga en cuenta que debe utilizarse como una red de seguridad. Aún intente capturar todas las excepciones antes de que se eleven tan lejos.

Answer 4

El impulso de atrapar todas las excepciones y hacer que el programa sea "estable" es muy fuerte y la idea parece muy atractiva para todos. El problema, como usted señala, es que esto es solo un truco y el programa puede tener muchos errores y, peor aún, sin indicaciones de fallos. Nadie supervisa los registros con regularidad.
Mi consejo sería intentar y convencer al otro desarrollador para que realice pruebas exhaustivas y luego implementarlo en la producción sin la captura externa.

Answer 5

Si desea ver la excepción cuando ocurra, en Visual Studio puede ir al menú DEBUG, seleccionar EXCEPTIONS y puede decirle al depurador que se interrumpa tan pronto como se lance una excepción. Incluso puedes elegir qué tipo de excepciones. :)