7

He hecho algunos proyectos hasta ahora, y me he dado cuenta de que todos y cada uno de ellos han escrito completamente sin ningún tipo de manejo de excepciones, luego al final hago muchas pruebas y manejarlos a todos.El momento adecuado para manejar todas las excepciones

¿Es correcto? recibo miles de excepciones mientras pruebo (que corrijo de inmediato) que si lo hubiera manejado no vería exactamente dónde está (cuando no utilice puntos de interrupción o lo muestre en cualquier parte ... pero no parece tan práctico) Así que soluciono los problemas comprobando cualquier excepción, y al final los manejo de todos modos por cualquier posible que pueda haber escapado (por supuesto).

¿Y usted? ¿Cuándo se ocupan de las excepciones?

+1

Las preguntas abiertas deben ser wikis comunitarios. Además, debe especificar claramente si tiene un lenguaje en mente. De lo contrario, márquelo como agnóstico del idioma. –

Respuesta

3

Personalmente, siempre defino un administrador global de excepciones no controladas apropiado para el tipo de aplicación y tengo esas excepciones de registro y correo electrónico para mi equipo de desarrollo. Durante el control de calidad, comenzaremos a agregar una administración de excepción específica a las rutinas que tienen problemas predecibles (y recuperables). En todos los casos posibles, agregamos código de programación defensivo para que las excepciones no sucedan en absoluto. (No hay necesidad de atrapar una excepción si puede probar antes de probar el código que podría fallar.)

Mis aplicaciones tienden a terminar con muchos códigos defensivos (que deberían estar incorporados desde el principio) y solo algunos específicos manejo de excepciones.

+0

estaba haciendo algo así durante la programación. Avísame si estoy equivocado. cuando se reciben datos de una fuente externa, si se prueba si están vacíos antes de usarlos, entonces, el uso de las precauciones deseadas es un ejemplo de código defensivo. – Marcelo

+0

Justo a la derecha, Marcelo. Compruebe si un objeto es nulo antes de llamar a sus métodos, etc. –

1

Yo diría que esto es al revés (pero común).

Es posible que desee buscar en el desarrollo basado en pruebas, y probar el primer diseño

Sugerencia: pensar en un comportamiento, escribir código para probar, añadirlo a su aplicación.

2

Prefiero el desarrollo basado en pruebas. Si hay una condición de error esperada, entonces prueba para ello. Si surge un error inesperado, realice una prueba y luego corríjalo.

1

Deseo definitivamente tenga en cuenta las excepciones producidas a medida que desarrolla cada interfaz y módulo.

De esta manera puede probar que son arrojados de manera confiable (cuando lo espera y no cuando no lo hace). Los componentes que consumen estos componentes pueden escribirse para conocer estas excepciones y manejarlas (o no según lo requieran).

Me parece que ignora algunas funciones de los componentes que está desarrollando. Virtualmente siempre probaré tanto la funcionalidad correcta como las circunstancias excepcionales, para cubrir tantos escenarios como pueda tan pronto como pueda.

+0

De acuerdo. Prefiero documentar (en XML comentarios) excepciones que pueden arrojarse por métodos cuando sea posible. – TrueWill

0

La respuesta a esta es una muy clara "depende".

Necesita ver la situación específica; ¿Se lanza una excepción en una pieza específica de código donde es posible recuperar o manejar la situación "excepcional" que da como resultado la excepción lanzada? En ese caso, sí, capte la excepción y trátela en ese nivel.

Por otro lado, ¿está hablando de errores no recuperables? Entonces, seguro, captúrelos a un nivel más global, o posiblemente nada (es decir, si no hay nada que pueda hacer con respecto a la excepción, ¿por qué la atrapa?)

+0

"Lo captas" para que puedas intentar colgar de forma responsable, si es posible, aunque, por supuesto, en algunos casos la aplicación puede estar en un estado demasiado caótico para siquiera molestarte en intentarlo. – Dereleased

+0

Si existe la capacidad de "bloquear de forma responsable", aún así lo categorizaría como una situación en la que se puede manejar una situación excepcional. Sin embargo, algo así como una excepción de memoria no se puede manejar de manera confiable (el código de manejo podría ocasionar que el mismo problema vuelva a suceder) y por eso considero que es un error "no recuperable". –

0

La regla de dónde detectar excepciones suele ser: donde sea es el lugar donde puedes manejarlos de manera significativa.

0

A veces depende de la tecnología o plataforma de destino.Por lo general, prefiero una capa de manejo de excepciones que se encarga de todas las excepciones. Cada bloque de código se encuentra dentro de un bloque try catch.

En pocas palabras, el sistema operativo o cualquier otra entidad ajena al programa o código no debe capturar ninguna excepción.

0

La belleza de las excepciones en comparación con los códigos de error de devolución de las API es que no tiene que comprobar las excepciones en cada capa de su código. Puede detectar excepciones específicas para determinar condiciones de error específicas y quizás manejar el error o volver a lanzar una excepción más apropiada. También debe detectar excepciones de alto nivel en su aplicación para evitar excepciones no controladas.

Una cosa a tener en cuenta es que generalmente el usuario de la excepción es el desarrollador y no el usuario final. El último normalmente no aprecia los detalles técnicos de las excepciones.

0

Lo más común que he visto es que los desarrolladores tomen una decisión consciente sobre el nivel para manejar las excepciones y permitir que sean lanzadas. Normalmente estará en el nivel de un hilo de trabajo, o un alto nivel de lógica de negocios. Permita que ocurran las excepciones, y tenga un método general para manejarlas/registrarlas y proteger al usuario de ellas.

El tiempo es la única diferencia entre lo que normalmente sucede y lo que haces. Planifique en sus aplicaciones desde el principio y realice el manejo de excepciones en niveles altos.

La reparación de excepciones específicas se realiza a través de su método de reparación cuando es un problema. Algunas veces, una biblioteca que uso usará innecesariamente excepciones para comunicar información, y agregaré un manejo especializado de excepciones a todas las llamadas a esa biblioteca. A menudo haré esto en una clase contenedora que oculta la implementación y el manejo de excepciones del resto de mi aplicación.

Cuestiones relacionadas