Niveles de depuración al escribir una aplicación

Question

Me gustaría saber si ustedes tienen alguna sugerencia sobre los niveles de depuración al escribir una aplicación.

pensé en 4 niveles:

0: no debug
1: Todas las entradas y salidas
2: "Estoy aquí" notificación de las funciones importantes con los parámetros principales
3: Todas las variables verbosa

Answer 1

lo que elija, habrá algo que quería ver que es sólo en el siguiente nivel ...

no creo que hay una respuesta general a esta pregunta, becaus Es tan dependiente de lo que hace la aplicación. Al igual que las aceitosas páginas del manual de Haynes (los lectores del Reino Unido sabrán a qué me refiero), tiendo a pensar que terminas con grandes talas en las áreas que tradicionalmente han sido problemáticas, y casi ninguna en el área que va a causar tiene problemas siguiente.

Answer 2

Esta es mi lista: relacionado depuración nada

aplicación emite:

• -modo silencioso. Bajo ninguna circunstancia la aplicación emitirá nada a UART o a la consola de depuración.
  • de error de modo:

  duro y los errores no-recuperables están registrados en la consola.

  • Advertencia-Mode:

  Permite la depuración-información extra destinado a ayudar a otros programadores.

  Este modo no está destinado a detectar errores, sino a proporcionar información a otros programadores que usan mis aplicaciones/biblioteca. En el modo de advertencia, principalmente reviso los parámetros de entrada y trato de detectar si alguien intenta hacer algo estúpido. Al igual que la fuerza bruta, una solución o pasar solo el tipo de datos más lento.

  • el modo de depuración (Nivel 1-4)

  En el modo de depuración comienzo a registrar todo, ordenados por frecuencia de ocurrencia. El nivel uno no es muy detallado. Las cosas importantes que mi programa/aplicación ha hecho se registran. No mucho mas. Este modo está destinado a ser utilizado para tener una idea aproximada de lo que hace un cliente.

  Cuanto mayor sea el modo de depuración, más información se registrará.

  Mi mayor nivel de depuración está reservado para todas las comunicaciones entre procesos y entrelazados. Todos los accesos a semáforos, mutexes ect se registrarán con la mayor cantidad de detalles posible.

Answer 3

Esto es lo que hicimos en un proyecto en el que trabajé. No es la Biblia de los niveles de registro, solo una posibilidad. El registro debe ajustarse a su situación.

• LOG_SEVERE, errores graves que requieren la salida del programa (por ejemplo, en una aplicación, se quedó sin espacio en el disco).
• LOG_ERROR, mensajes de error de los que no se puede recuperar pero el programa puede seguir ejecutándose (por ejemplo, en una aplicación de servidor, el cliente envía datos incorrectos pero otros clientes pueden continuar ejecutándose).
• LOG_WARNING, problema recuperable por el que debe recibir una notificación (p. Ej., Valor no válido en un archivo de configuración, por lo que vuelve al valor predeterminado).
• LOG_INFO, mensajes informativos.
• LOG_ENTRY, inicie sesión y salga de todas las funciones.
• LOG_PARM, ingrese la entrada y la salida de todas las funciones con parámetros aprobados y valores devueltos (incluidos los efectos globales, si los hubiera).
• LOG_DEBUG, mensajes generales de depuración, información básicamente útil que se puede generar en una sola línea.
• LOG_HIDEBUG, mensajes de depuración mucho más detallados como volcados hexadecimales de almacenamientos intermedios.

Cada nivel también registró mensajes en niveles 'inferiores'. A veces, se preguntaba si un mensaje de depuración debería ser LOG_DEBUG o LOG_HIDEBUG, pero básicamente lo basamos en el número de líneas que enviaría al archivo de registro.

Answer 4

Lo que es realmente más importante con los diferentes niveles de registro es que todos los desarrolladores están usando las mismas definiciones.

He visto ejemplos de desarrolladores que registran un error de un paquete tcp cuando no entregan un paquete aunque se maneje y la persona que realiza el reenvío realiza un reenvío.
El desarrollador en cuestión dijo: "Pero en este contexto, es un error".

es necesario definir cosas como:
significa un error que la aplicaciónha fallado y necesita ser reiniciado.
Una advertencia puede meen que una sola función de la aplicación ha fallado, sino que la aplicación puede recuperar y continuar
y así sucesivamente ...

El número exacto de los niveles no es tan importante como en el uso consistente de esos niveles a lo largo de la aplicación.

Puede ser muy útil si es posible cambiar los niveles durante el tiempo de ejecución y, si es posible, seleccionar diferentes niveles para diferentes partes de la aplicación.

Answer 5

sangré para separar los registros de depuración de los registros de auditoría y de excepción. por lo tanto, los registros que son informáticos como, por ejemplo, la función SendMessage que finalizó correctamente o no serán registros de auditoría, pero los registros de cualquier falla de la aplicación para enviar ese mensaje que causó una excepción serán los registros de excepción.

Los registros de depuración están destinados a ser utilizados solo con fines de depuración. los niveles son para que yo elija qué tan severa será la depuración.

Creo que para los desarrolladores que trabajan en grupo es importante establecer estas reglas incluso antes de comenzar a codificar ... por lo que el registro será consistente.

¡Gracias por las buenas sugerencias!

Omri.

Answer 6

que tengo:

• Crítico/Fatal, el programa puede no poder continuar, normalmente el usuario perdió.
• Error, algo realmente incorrecto, los datos usados ​​pueden estar dañados, pero puede tener suerte.
• Advertencia, esto no está bien, puedo continuar, pero por favor eche un vistazo.
• Sugerencia/Información, me gusta decir algo, pero no espero que me escuchen.
• Depurar, toda la información sólo es interesante para los programadores.

Normalmente, los dos niveles más bajos están bloqueados. Pero los otros se muestran. Y si quieres bloquear el nivel Fatal, está bien para mí, pero no esperes que lo limpie después (desafortunadamente todavía tengo que ...).

Answer 7

0: ningún registro

1: registro de excepción: registrar cada error que se produce. Por ejemplo, en C#: iniciar sesión en bloques catch. Cuando se activan estas operaciones de registro, usted sabe que tiene un error. También puede iniciar sesión en las declaraciones de cambio si hay un caso que nunca se debe golpear y similares.

2: registro de operación: las operaciones de registro, que no están en bloques catch (operaciones normales), se deben establecer en una depuración alta. De esta forma, puede ver qué método comienza a ejecutarse y luego termina en un bloque catch.

Además, piense en los conmutadores de registro, por ejemplo, el registro de paquetes (verdadero: registrar paquetes/mensajes de red, falso: no hacerlo). Simplemente no exagere con los interruptores.

En el manejo de excepciones, cada cuerpo de método debe estar al menos en un bloque try-catch, al menos con un catch de excepción general al final. Coloque el registro en el bloque catch, agregue información opcional además del mensaje del sistema y el seguimiento de la pila para indicar qué causó el error, luego arroje el error. Deje de arrojar errores aún más cuando se haya notificado al usuario sobre el error, o si se encuentra en el nivel superior de una aplicación, que no tiene una interfaz de usuario activa. (Registro del lado del servidor, por ejemplo). Luego debe indicar en un mensaje a la aplicación del cliente que ha ocurrido un error en el servidor.

Answer 8

Normalmente he usado más de cuatro niveles, aunque no necesariamente tienen nombres. Puede consultar los niveles provistos por el proceso del demonio 'syslog'.

0 - Emergency (emerg) 
1 - Alerts (alert) 
2 - Critical (crit) 
3 - Errors (err) 
4 - Warnings (warn) 
5 - Notification (notice) 
6 - Information (info) 
7 - Debug (debug) 

(El paquete log4j añade un nivel por debajo de 'depuración' llamada 'Rastro', pero proporciona sólo 'fatal', donde syslog y syslogd proporcionan emergencia, alertas y Crítico.) Estos no son directamente relevantes, pero deben dar Te detuviste a pensar. La lista provista por Pax es bastante razonable.

Una cosa que a menudo he encontrado útil es la segmentación de la depuración: diferentes niveles de depuración configurables para diferentes componentes del sistema. Por ejemplo, dependiendo de dónde esté el problema, podría necesitar una gran depuración en la sección de entrada y en la sección de administración de macros, sin necesitar ninguna depuración en el código de procesamiento principal. Un único nivel de depuración en todo el programa es considerablemente mejor que nada, pero para los programas complejos, la diferenciación es invaluable.

Puede encontrar la fuente que utilizo en GitHub en mi repositorio SOQ (Stack Overflow Preguntas) como archivos debug.h, debug.c, mddebug.c en el subdirectorio src/libsoq .