¿Cómo enseñar el manejo de excepciones para nuevos programadores? [cerrado]

21

¿Cómo se hace para enseñar el manejo de excepciones a los programadores? Todas las demás cosas se enseñan fácilmente - Estructuras de datos, ASP.NET, WinForms, WPF, WCF - lo que sea, todo se puede enseñar fácilmente.

Con el Manejo de Excepciones, enseñarles probar-capturar-finalmente es solo la naturaleza sintáctica del Manejo de Excepciones.

Sin embargo, lo que se debe enseñar es: ¿qué parte de tu código pones en el bloque intentar ? ¿Qué haces en el bloque captura ?

Déjame ilustrarlo con un ejemplo.

Está trabajando en un proyecto de Windows Forms (una pequeña utilidad) y lo ha diseñado de la siguiente manera con 3 proyectos diferentes.

  1. UILayer
  2. BusinessLayer
  3. DataLayer

Si se genera una excepción (digamos que cargar un XDocument lanza una excepción) en DataLayer (el UILayer llama a BusinessLayer, que a su vez llama al DataLayer), simplemente haga lo siguiente

//In DataLayer
try {
    XDocument xd_XmlDocument = XDocument.Load("systems.xml");
} 
catch(Exception ex)
{
    throw ex;
}

¿Qué se lanza de nuevo en BusinessLayer y cuál se atrapa en UILayer donde lo escribo en el archivo de registro?

¿Es así como se hace con el Manejo de excepciones?

    
pregunta Kanini 26.10.2010 - 18:21

9 respuestas

29

Para explicar el manejo de excepciones, explique el concepto subyacente: El código donde ocurre un error con frecuencia no sabe cómo manejar adecuadamente ese error. El código que sabe cómo manejarlo adecuadamente podría ser el función que lo llamó, o podría estar más arriba en la pila de llamadas.

Cuando escribe una rutina que llama a una rutina que podría generar una excepción, si sabe cómo manejar ese error correctamente, coloque la llamada en un bloque try y coloque el código de manejo de errores en el bloque catch. Si no, déjelo en paz y deje que algo por encima de usted en la pila de llamadas maneje el error.

Decir "catch ex, throw ex" no es una buena manera de manejar excepciones, ya que en realidad no maneja nada. Además, dependiendo de cómo funciona el modelo de excepción en su idioma, eso puede ser perjudicial si borra la información de seguimiento de la pila que podría haber utilizado para depurar el problema. Simplemente deje que la excepción se propague por la pila de llamadas hasta que llegue a una rutina que sepa cómo manejarla.

    
respondido por el Mason Wheeler 26.10.2010 - 18:28
13

Como la mayoría de las cosas, es probable que las excepciones y el manejo de excepciones parezcan una solución en busca de un problema para los nuevos programadores hasta que demuestre por qué la solución aparentemente más simple (códigos de retorno de estilo C y errno) funciona tan mal. Empezaría por motivar el problema y ponerlo en contexto. Muestre cómo se puede hacer el manejo de errores usando códigos de retorno o variables globales / estáticas. Luego da ejemplos de por qué no funciona bien. Entonces y solo entonces, introduzca las excepciones y explique que son una forma de señalización fuera de banda y que el punto entero es que el comportamiento predeterminado si ignora una excepción es pasar la pelota la pila de llamadas a alguien que puede manejarlo.

Conclusión: mostrar cómo se realizó el manejo de errores en C hará que los estudiantes comprendan para qué sirven realmente las excepciones y por qué detectar las excepciones que realmente no se pueden manejar es básicamente simular la forma en que se hicieron las cosas en la Edad Media.

    
respondido por el dsimcha 29.10.2010 - 23:09
5

Comenzaría con Pautas de diseño para excepciones es breve e incluye HACER, NO HACER y EVITAR. También da las razones por las que.

En su caso de ejemplo, la sección de revelado sería Envolviendo excepciones

Y esperaría que fuera escrito de esta manera. Tenga en cuenta que detecta una excepción específica e intenta agregar información para que se propague un mensaje más significativo. También tenga en cuenta que la excepción interna todavía se mantiene para fines de registro

//In DataLayer

try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
        throw new TransactionFileMissingException(
                     "Cannot Access System Information",ex);
}

ACTUALIZACIÓN Kanini pregunta si es correcto tener este bloque de excepción en la capa de datos o si la verificación del archivo está disponible para la capa empresarial.

Bueno, primero me gustaría señalar que la razón de envolver excepciones es la siguiente

  

Considere envolver excepciones específicas   lanzado desde una capa inferior de una manera más   excepción apropiada, si el menor   excepción de capa no tiene sentido en   El contexto de la capa superior.   operación.

Entonces, si sientes que una capa superior debería conocer el archivo, tu capa de datos debería tener este aspecto

//In DataLayer

XDocument xd_XmlDocument = XDocument.Load("systems.xml");

No intente sin captura.

Personalmente, creo que a menos que su capa de datos pueda hacer algo útil, como usar un system.xml predeterminado que es un recurso de ensamblaje, no hacer nada o envolver la excepción es una buena apuesta ya que su registro le dirá qué método y qué archivo fue el problema. ( throw ex en este caso o el preferido throw también lo hace pero no agrega ningún valor). Esto significa que una vez identificado, podrá solucionar el problema rápidamente.

Como ejemplo, este ejemplo en particular también tiene el siguiente problema, ya que XDocument.Load puede generar cuatro ejecuciones

  • ArgumentNullException
  • SecurityException
  • FileNotFoundException
  • UriFormatException

No podemos garantizar de forma segura que el siguiente código no se lanzará y la excepción FileNotFoundException, simplemente porque podría estar allí cuando verifiquemos la existencia y desaparezcamos cuando cargamos. Tener eso disponible para la capa de negocios no ayudaría.

 if (File.Exists("systems.xml")) 
     XDocument.Load("systems.xml");

La excepción SecurityException es aún peor porque, entre otras razones para que esto ocurra, si otras tomas de proceso tienen un bloqueo de archivo exclusivo, no obtendrá el error hasta que intente abrirlo para leerlo porque no existe el método File.CanIOpenThis () . Y si tal método existía, todavía tiene el mismo problema que con File.Exists

    
respondido por el Conrad Frix 27.10.2010 - 23:05
4

Vamos a hacer un juego de roles. (Esto no es una publicación de broma)

Debes hacer un taller donde representas la cadena de llamadas. Cada persona es un objeto. Necesitarás algunos novatos y algunas personas que entiendan el "juego" ayudan.

Use un problema realmente simple como el archivo IO. gui- > model- > file_io

La persona que está siendo el lector de archivos debe contar la siguiente ...

Primero hazlo con los códigos de retorno. (usa notas post-it?)

si las interacciones son simplemente "lo que dice el código", pronto podrás hacer que las personas se den cuenta de que las excepciones son excepcionales.

para los códigos de devolución, pase una nota post-it.

para excepciones, lance sus manos al aire y diga cuál es el problema.

luego, pídales que hagan "capturar x, lanzar x" y vean que, mucho peor, el diagnóstico es lo que la GUI solo obtiene "el modelo tenía una excepción".

Creo que esto funcionará para capacitar a las personas que tienes porque las personas entienden muy bien las interacciones con otras personas.

    
respondido por el Tim Williscroft 02.11.2010 - 23:43
1

Me imagino que para entender las excepciones, primero debe comprender la relación de clases entre niños y padres, por ejemplo. Si entiende que un hijo puede heredar la funcionalidad de un padre, en un nivel elemental podría comprender que si un hijo tiene un problema que no puede manejar, pasará este problema (excepción) a su padre y permitirá que el padre se ocupe. con eso.

Esto se convierte en una relación encadenada hasta que terminas con un lugar donde algo sabe cómo manejar la excepción.

Y hasta donde finalmente llega, esta es la parte trivial ... cuando ocurre un problema, algo tiene que manejarlo para que el programa no salga fatalmente, después de que se maneja esa excepción, el bloque finally está ahí, que siempre se ejecutará independientemente de el intento de captura.

Un buen ejemplo de esto podría ser con la red:

  • hacemos conexión
  • la conexión está bien, así que la usamos
  • cuando hayamos terminado, nos cerramos y liberamos recursos

o en caso de excepción:

  • hacer una conexión
  • ocurre una excepción que algo maneja
  • En qué punto liberamos la conexión y los recursos asociados
respondido por el Chris 26.10.2010 - 18:57
1

Entregue una solicitud al novato que tenga un muy buen manejo de excepciones. Lance alguna excepción en algún lugar y déjelos depurar con la ayuda de Logs. Al rastrear la propagación de Excepciones, deberían poder depurarlo. Haga este ejercicio 3 o 4 veces. Ahora simplemente elimine todo el manejo de Excepciones del código y deje que intenten rastrear la misma excepción.

Creo que la apreciación por el código de Manejo de Excepciones se apreciará instantáneamente.

    
respondido por el Geek 02.11.2010 - 16:58
0

OMI, debe pensar que las declaraciones de control de flujo y manejo de excepciones son básicamente las mismas. Los usa para controlar el flujo de sus programas según la condición en la que se encuentran actualmente. La diferencia es que el manejo de excepciones solo reaccionará cuando se produce un error (o excepción).

    
respondido por el denny 01.11.2010 - 16:22
0

Probablemente no ayudaría a un nuevo programador, pero descubrí que entendía el concepto de excepciones mucho mejor una vez que empecé a usar mónadas en la programación funcional. Una mónada lo obliga a considerar cada "canal" a través del cual los datos pueden viajar dentro o fuera de un programa, ya que todo lo que hace proporciona una abstracción conveniente para "ocultar" parte de ese flujo de datos.

La idea de que una función puede tener diferentes tipos de salida, y una excepción es como un tipo de retorno de mayor prioridad de la función es bastante clara.

Eso sí, entiendo que no es así como funcionan las excepciones en la mayoría de los lenguajes (detalles de implementación), pero en un sentido abstracto, eso es lo que está sucediendo.

    
respondido por el CodexArcanum 04.11.2010 - 19:32
0

Imagina que un mono está usando el teclado

Solía decirles a mis muchachos cuando están escribiendo un código para fingir que un mono estará sentado en el teclado y usando esta aplicación.

Esto les enseñó a anticipar todo tipo de cosas:

  • datos faltantes
  • Faltan archivos
  • caracteres alfa cuando esperas números
  • División por cero

Creo que fue la imagen de una imagen de tener un mono simplemente golpeando las teclas y haciendo lo que quería, en lugar de seguirlo bien, lo que hizo el truco. Funcionó para mí.

    
respondido por el Michael Riley - AKA Gunny 06.11.2010 - 17:34

Lea otras preguntas en las etiquetas