¿Cómo puedo mejorar mi comprobación y manejo de errores?

La forma más fácil para que yo sepa la diferencia es determinar si la condición de error se introduce en el momento de la compilación o el tiempo de ejecución. Si el problema es que un programador está utilizando la función de manera incorrecta, haga una afirmación para llamar la atención sobre el problema, pero una vez que la solución se compila en el código de llamada, no necesita preocuparse más por verificarlo. Los problemas, como quedarse sin memoria o la entrada incorrecta del usuario final no se pueden resolver en el momento de la compilación, por lo que deja las comprobaciones.

Verifique cualquier cosa en cualquier momento (podría haber cambiado después de su última revisión) que no está al 100% bajo el comando su . Y también: ¡Durante el desarrollo incluso no confíes en ti mismo! ;-)

Okokok ... "cualquier cosa" debe interpretarse como una comprobación de cosas que podrían provocar un anormal o cualquier cosa que pueda hacer que su aplicación / sistema haga cosas que no debería hacer.

Para ser serio, la última parte de la última oración es esencial porque apunta al problema principal:

Si desea construir un sistema estable, la principal preocupación no es lo que debe hacer el sistema, sino que, para permitirle hacer cosas tan obligatorias, debe cuidar lo que debería no do, incluso si "desordena tu código".

El quid de la gestión de errores no es si se soluciona el problema y cómo lo hace. Es más de lo que haces después de que lo aprendes .

En primer lugar, yo diría que no hay ninguna razón por la que no se pueda manejar un solo error devuelto por un método subordinado. Y los errores y las excepciones son más que los valores de retorno o todos los intentos / capturas.

1. No basta con lanzar y atrapar.
   Ver esto : donde El autor explica que solo atrapando pero sin hacer nada. potencialmente suprime la excepción y, a menos que se haga lo suficiente para deshaga el daño, es peor que dejar que el código se vaya como ese. Del mismo modo, solo se escribe una declaración "log" cuando hay un archivo el error de abrir o leer podría ayudar a encontrar el motivo, pero para el momento programa termina, podría haber causado que los datos se dañen! Eso no es suficiente para decir que tengo muchos try / catch - es más importante para saber lo que realmente hacen!

2. No abuses del try and catch.
   Algunas veces, los programadores en su mayoría perezosos o ingenuos piensan que después de escribir suficientes intentos / capturas, su trabajo ha terminado y es fácil. Muy a menudo, es mejor aplicar acciones correctivas y reanudar en lugar de simplemente deshacerse de todo. Si esto no se puede hacer, uno debe decidir a qué nivel necesita volver. Según el contexto y la gravedad, el diseño de anidamiento de capturas requiere un diseño cuidadoso. Por ejemplo- Ver esto y esto

3. Defina quién es responsable:
   Una de las primeras cosas que debe hacer es definir si la entrada dada a la rutina en sí es solo un escenario inaceptable (o no se ha manejado hasta ahora) o si es la excepción debida al entorno (como un problema del sistema, un problema de memoria), o ¿Es esta situación un resultado completamente interno del resultado del algoritmo? En todos los casos, el nivel al que desea volver o la acción que desea realizar difiere significativamente. En este sentido, me gustaría decir que cuando se ejecuta el código en producción, hacer un aborto () para salir del programa es bueno, pero no para todas las cosas pequeñas. Si detectas corrupción de memoria o falta de memoria, es definitivo que incluso después de hacer lo mejor posible, las cosas morirán. Pero si recibe un puntero NULO en la entrada, no seguiría llamando a abort (), preferiría enviarlo a la persona que llama con un error y ver si es lo suficientemente inteligente como para saber si se puede corregir.

4. Defina cuál es el mejor resultado posible:
   Lo que todas las cosas deben hacerse bajo excepción es muy crítico. Por ejemplo, si en uno de nuestros casos, un reproductor de medios encuentra que no tiene datos completos que deben ser reproducidos por el usuario, ¿qué debería hacer?

   • omitir alguna parte mala y ver si puede salir adelante con buena cosas.
   • si esto sucede, considera si puede saltar a la siguiente canción.
   • si encuentra que no puede leer ningún archivo, detenga y mostrar algo.
   • mientras tanto
   • bajo cuál del estado debe un jugador POP-UP para el usuario y
   • ¿Cuándo debería llevarse a cabo por sí solo?
   • En caso de que "detenga" las cosas para pedir comentarios a los usuarios
   • ¿O debería poner una pequeña nota de error en algún rincón?

   Todos estos son subjetivos, y quizás haya más formas de manejar los problemas de lo que nosotros pensamos. Todo lo anterior requiere construir y comprender la profundidad de la excepción y, además, hacer que diferentes escenarios sean posibles para evolucionar hacia.

5. A veces necesitamos verificar las excepciones antes de que surjan. los El ejemplo más común es el error de división por cero. Idealmente uno debe probar que antes de tal excepción es lanzada sobre - y si ese es el caso- trate de poner el valor distinto de cero más apropiado y seguir adelante que el suicidio!

6. Limpieza. Al menos esto es lo que debes hacer! Si una funcion sucede para abrir 3 archivos y el cuarto no se abre, no hace falta decir el Los primeros 3 deberían haber sido cerrados. Delegando este trabajo a una capa arriba es una mala idea Si decides no dejarte del todo. memoria de limpieza. Y lo más importante, incluso si has sobrevivido al excepción, informe más arriba que las cosas no han tomado el curso normal.

La forma en que vemos la funcionalidad (normal) del software en términos de varias jerarquías o capas o abstracciones, de la misma manera en que debemos categorizar las excepciones según su gravedad, así como el alcance bajo el cual surgen y están afectando a otras partes del sistema. - Eso define cómo manejar tales excepciones diferentes de la mejor manera posible.

Mejor referencia: Code Craft capítulo 6: disponible para descargar

La comprobación de errores solo durante las compilaciones de depuración es una IDEA MALA (tm), la compilación de las superposiciones de liberación sobre las variables reutilizables en la pila, elimina las páginas de guarda, hace trucos con los cálculos, reemplaza las artríticas pesadas con turnos precomputados, etc.

También puede utilizar la comprobación de errores en la versión, puede recurrir a algo tan simple como:

if(somethinghitthefan)
     abort();

Esto también tiene un efecto secundario muy bueno que definitivamente no ignorarás el error una vez que la aplicación comience a fallar en la PC de Betta Testers.

Los visualizadores y registros de eventos son completamente inútiles en comparación con abort() , ¿quién los revisa de todos modos?

Las diversas cosas que puedes hacer es
 1.Lea y asimila gran cantidad de código en línea y mira cómo se hace
 2.Utilice algunas herramientas de depuración para ayudarlo a localizar regiones de errores
3. Esté al tanto de errores triviales debido a asignaciones incorrectas y errores de sintaxis.
4. Surgen algunos errores peores debido a errores lógicos en el programa que son más difíciles de encontrar. Para esto, puede escribirlo y encontrarlo o, para los más complicados, intentar hablar con la gente o usar recursos como Stackoverflow , Wikipedia , google para obtener ayuda de las personas.