Imprimir postura correcta el registro de errores en el proyecto de Java, la solución de problemas y más conveniente, muy práctico!

latido del registro de errores en el objetivo principal del programa es proporcionar pistas y orientaciones para una mejor solucionar problemas y resolver problemas importantes. Pero jugando en la práctica el registro de errores contenido y el formato diverso, el error puede ser incompleta, sin fondo, su significado es desconocido, por lo que la investigación para resolver el problema se vuelve muy incómodo o que consume tiempo operación.

De hecho, si un poco de tiempo de programación con cuidado, se reducirá una gran cantidad de desperdicio de esfuerzo para solucionar el problema. Al explicar cómo escribir registro de errores eficaz para comprender cómo se generan errores, es muy importante.

Error Cómo hacer

Para que el sistema actual, el error generado por la introducción de tres lugares:

1. Sistema de nivel de parámetro ilegal introdujo.  Para la introducción del error de parámetro ilegal, el error se puede comprobar para interceptar y comprobar las condiciones previas parámetros;

2. interactuar con el error del sistema subyacente generado.  Y los errores generados por la interacción subyacente, hay dos:

. Un proceso de sistema menor es un éxito, pero un error de comunicación, y esto conducirá a la inconsistencia de datos entre los subsistemas;

En este caso, un tiempo de espera puede ser mecanismo de compensación empleada, tarea previamente grabada por la tarea programada sobre la revisión de datos subsiguiente.

Lo mejor diseño, puede dejar un mensaje.

B. comunicación exitosa, pero el más bajo es el procesamiento de errores.

En este caso, la necesidad subyacente para comunicarse con los desarrolladores, coordinar las interacciones entre subsistemas;

necesidades de tratamiento apropiados por hacer para dar un mensaje razonable o el código de error y la descripción de error de retorno inferior.

En cualquier caso, debemos asumir que la fiabilidad del sistema subyacente en, buena error general consideraciones de diseño.

3. El error de procesamiento sistema de capas.

Esto produjo un error del sistema de capas:

Una de las razones:  negligencia.  La negligencia se refiere al programador la capacidad de evitar por completo este tipo de errores, pero en realidad no lo hacen. Tales como la detonación sería y &&, convertido golpeando = ==; errores de contorno, los errores compuestos juicio lógico. Negligencia o programadores carecían de concentración, como en un estado de fatiga, las horas extraordinarias durante toda la noche, mientras se está sentado y un programa de escritura, ya sea a toda prisa para realizar la función, no tienen en cuenta la solidez del programa y así sucesivamente.

Mejoras: utilizar la herramienta de análisis de código estático, la cobertura de la línea por unidad de pruebas puede evitar efectivamente el problema.

Dos razones:  el error y manejo de excepciones debido a bastante a fondo.   Por ejemplo, el problema de entrada. Calcula dos números, no sólo considerar desbordamiento de cálculo, sino también en cuenta el caso de entrada ilegal. En el primer caso, posiblemente a través de la comprensión, la experiencia o los errores se pueden evitar, y para este último, debe limitarse de modo que está dentro del alcance de nuestra inteligencia puede controlar, como el uso de expresiones regulares para filtrar entrada no válida. Para la expresión regular, tienen que ser probado. Para la entrada ilegal, en la medida de lo posible para dar una detallada, fácil de entender, mensaje amistoso, causas y recomendar soluciones.

Mejoras: consideran las diversas condiciones de error y excepciones como pensativo.  Después de la realización del flujo principal, un paso adicional: examen cuidadoso de una variedad de posibles errores y excepciones, devoluciones razonables un código de error y descripción del error. Cada módulo de interfaz es válido o manejar sus propios errores y excepciones, que puede evitar efectivamente el error causado debido a un complejo escenarios de interacción.

Por ejemplo, un escenario de caso de uso de negocio realiza por la interacción ABC. AB ejecución real tuvo éxito, no C, entonces B y la necesidad de devolver el código C razonable de acuerdo con el mensaje y vuelve a la reversión Un mensaje de código razonable y, de acuerdo con el regreso B Una reversión, y devuelve al cliente razonable código y mensaje. Esto es necesario establecer un mecanismo de reversión segmentada en cada escena excepciones Revertir deben ser considerados.

Por tres razones:  la lógica plomo fuertemente acoplado.  A medida que la lógica de negocio estrechamente unida, con el paso a paso el desarrollo de productos de software, todo tipo de relaciones lógicas son complicadas, difíciles de ver la situación global, lo que lleva a la influencia de la diseminación local de modificar el alcance global, causa problemas impredecibles.

Mejoras: funciones cortas y métodos cortos de escritura, cada función o método preferiblemente no más de 50 líneas.  funciones de escritura sin estado y los métodos de sólo lectura de estado global, y la salida es siempre un requisito previo para el mismo resultado, no se basan en el estado externo cambia su comportamiento; definición razonable de la estructura de la sección de interfaz y la lógica, de modo que la interfaz entre el posible interacción ortogonal, bajo acoplamiento; capa de servicio para proporcionar tan simple como sea posible, ortogonal a la interfaz; remodelación continua, manteniendo la modularidad y aplicaciones débilmente acoplados, dependencias lógicas tipo.

Para un gran número de interfaces de servicio se influyen mutuamente, los procesos de la lógica de negocio deben disponer de interfaces e interdependencias, para optimizar su conjunto, el estado de un gran número de entidades, sino también la necesidad de resolver la transición pertinente entre la interfaz de servicio, el estado de acabado las relaciones.

Cuatro razones:  el algoritmo no es causa correcta.

Mejoras: En primer lugar, el algoritmo está separada de la aplicación.  Si algoritmo múltiple implementado, se puede encontrar por poner a prueba unidad de validación cruzada, tales como operación de clasificación; si la naturaleza reversible de la algoritmo puede averiguar mediante la comprobación de las pruebas de unidad reversibles, tales como operaciones de cifrado y descifrado.

Cinco razones:  el mismo tipo de parámetros pasados en errores en los pedidos.  Por ejemplo, modifyFlow (int rx, tx int ), la llamada real es modifyFlow (TX, RX)

Mejoras: tanto como sea posible el tipo de hormigón.  El número de coma flotante con un flotador, una cadena a la cadena, a utilizar el tipo particular de tipos de objetos objeto específico; el mismo tipo de desplazamiento como parámetros, y si no la lata de arriba se reunió, se debe verificar mediante pruebas de la interfaz los valores de los parámetros de interfaz deben ser diferentes.

Seis razones:  Excepción de puntero nulo.  Excepción de puntero nulo es por lo general el objeto no se ha inicializado correctamente o no hay ningún objeto que no esté vacía para hacer pruebas antes de utilizar el objeto.

Mejoras:  Para los objetos de configuración, detectar si se ha inicializado correctamente;  para objetos ordinarios, adquirido objeto de entidad antes de su uso para detectar si un no vacío.

Siete razones:  error de comunicación de red.  Error de comunicación de la red por lo general mal porque el retardo de red, obstrucción o barrera causados. errores de comunicación de red son generalmente evento de baja probabilidad pequeña, pero una pequeña probabilidad de un acontecimiento es probable que resulte en el fracaso de un área grande, es difícil de reproducir el error.

Mejora:  el punto extremo frontal de un subsistema y unos puntos de entrada del subsistema de cada registro después de jugar INFO.  Proporcionar una pista por la diferencia de tiempo entre los dos.

La razón de ocho:  Transacciones y concurrencia errores.  Al mismo tiempo que el conjunto de transacciones, es propenso al error muy difícil de localizar.

Mejoras:  Para los programas de operaciones concurrentes que involucran variables compartidas y los cambios de estado importantes, así como la elevación de registro INFO.

Si hay un enfoque más eficaz, dijo que el mensaje de bienvenida.

La razón Nueve:  error de configuración.

Mejoras:  cuando se inicia una aplicación o iniciar la configuración adecuada, detecta todos los elementos de configuración, imprimir el registro INFO apropiada para asegurar que todas las configuraciones se cargan correctamente.

La razón de diez:  Negocio de error desconocido.  En sistemas grandes, que forma parte de la lógica de negocio y las interacciones de negocios son más complejos, toda la lógica de negocio puede existir en el desarrollo cerebral múltiple de los alumnos, la comprensión de todos no es completa. Esto puede conducir fácilmente a errores de codificación de negocio.

Mejoras:  por más de discusión y comunicación, diseño los casos adecuados de uso del negocio, de acuerdo con la empresa para escribir y ejecutar los casos de uso de lógica de negocio,  la lógica empresarial fundamental y los casos de uso del negocio deben estar archivo completo; condiciones previas indican el servicio en una interfaz de servicio, el procesamiento de la lógica, y las precauciones suma de comprobación posterior, cuando los cambios de tráfico deberán actualizarse de forma sincrónica comentario servicio; revisión de código. Notas negocio es una interfaz de documentos de negocios importante, la empresa juega un papel importante en la comprensión de la memoria caché.

La razón XI:  los errores causados por problemas de diseño.  Por ejemplo, no habrá manera en serie síncrona rendimiento, el problema de la lenta respuesta, el rendimiento asíncrono y concurrente puede ser resuelto, el problema de respuesta lenta, pero traerá seguridad, precisión de riesgo. modelo de programación asincrónica puede dar lugar a cambios, añadir otras nuevas y recibir mensajes de inserción asincrónica y así sucesivamente. Podemos utilizar el almacenamiento en caché para mejorar el rendimiento, sino que hay una actualización de la memoria caché problema.

Mejoras:  la escritura y la revisión cuidadosa de los documentos de diseño.  Los documentos de diseño deben elaborar fondos, necesidades, se cumplen los objetivos de negocio, para lograr las métricas de rendimiento empresarial puede afectar las ideas de diseño generales, el programa detallado, el programa prevé la ventajas y desventajas y posibles impactos; pasar la prueba y la aceptación, para asegurar que el cambio diseño hace reúnen objetivos de negocio y las métricas de rendimiento de negocio.

La razón 12:  errores causados por detalles desconocidos.  Tales como desbordamientos de búfer, ataques de inyección SQL. Desde un punto de vista funcional, no hay ningún problema, pero el uso del punto de vista malicioso, es vulnerable. Otro ejemplo, optar por hacer la biblioteca Jackson JSON análisis de cadenas, de forma predeterminada, cuando un nuevo objeto de campo puede causar errores de análisis. Debe ser añadido @JsonIgnoreProperties (ignoreUnknown = true) anotación para responder a los cambios correctamente en el objeto. Si elige otra biblioteca JSON no tendrá este problema.

Mejoras:  por un lado, a través de la experiencia, por el contrario, consideran que los problemas de seguridad y excepciones, seleccionar maduro biblioteca probado rigurosamente.

Trece razones:  errores que se produce con el tiempo.  Algunas de las soluciones en los últimos parece ser muy buena, pero puede resultar incómodo o incluso inútiles en los escenarios actuales o futuros, es una cosa común. Tal como algoritmo de cifrado y descifrado, en el pasado se puede considerar que ser perfecto, hay que tener precaución tras el descanso.

Mejoras:  prestar atención a los cambios y correcciones de errores, corrección oportuna de noticias de código de fecha, bibliotecas, comportamiento.

La razón 14:  errores relacionados con el hardware.  Tal como pérdidas de memoria, la falta de espacio de almacenamiento, OutOfMemoryError y así sucesivamente.

Mejoras:  sistema de monitoreo de rendimiento de las aplicaciones aumento es un indicador importante de CPU / memoria / redes.

Los errores comunes que se producen en el sistema:

• Entidad registra en la base de datos no existe, que se debe especificar entidad o identificador de la entidad;

• Entidad no está configurado correctamente, debe especificar el problema de configuración, lo que debería ser la configuración adecuada;

• Los recursos físicos no cumple con los criterios, debe especificar qué recursos actuales son, qué recursos son necesarios;

• condiciones de funcionamiento de la entidad no se cumplen, lo precondiciones debe especificar la necesidad de cumplir, ¿cuál es el estado actual;

• Después no se cumple la operación de calibración del conjunto de entidades, la comprobación posterior debe indicar lo que hay que satisfacer, ¿cuál es el estado actual;

• Los problemas de rendimiento hacen que los tiempos de espera, debe indicar la causa de los problemas de rendimiento, la forma de optimizar el seguimiento;

• Estado de error o el resultado en datos inconsistentes entre múltiples subsistemas de comunicación interactiva?

Por lo general difíciles de localizar errores se producen en el lugar relativamente de bajo nivel. Debido a que el subyacente no se puede predecir escenarios de negocio específicos, el mensaje de error dado son relativamente comunes.

Para ello es necesario proporcionar pistas lo más rico posible en el negocio superior. Incorrecto es un cierto nivel de interacción o múltiples sistemas que no cumplen con las condiciones previas en una causa pila de capas. Durante la programación, cada capa de la pila debe tener cuidado para asegurar que todas las condiciones previas son satisfechos tanto como sea posible para evitar los parámetros erróneos se pasan a la parte inferior, tanto como sea posible error en la capa de negocio interceptada.

La mayoría de los errores se combinan para producir una variedad de razones.  Pero cada error debe tener una causa.  Después de resolver el análisis de errores, en profundidad de cómo se produjo el error, y cómo evitar que ocurran de nuevo.  Los esfuerzos pueden tener éxito, sin embargo: con el fin de reflexionar sobre el progreso!

Cómo escribir el registro de errores más fácil Solucionar problemas

de registro de errores ritmo principios básicos:

1. Lo más completa posible.  Cada descripción completa del registro de errores son: lo que salió mal en qué escenario, ¿cuál es la razón (o lo que sea posible razón), la forma de resolver (o consejos a resolver);

2. Lo más específico posible.  Por ejemplo, la insuficiencia de recursos NC, carecen de lo que se refiere específicamente a qué recursos, puede indicar directamente a través del programa; errores comunes, como la máquina virtual no existe, para indicar lo que sucedió en la escena, pueden facilitar el trabajo de las estadísticas de seguimiento.

3. Tan directamente como sea posible.  El registro de errores debe ser la mejor gente en el primer instinto es saber cuál es la causa, la forma de resolver, en lugar de tener que pasar por varios pasos para encontrar la verdadera razón.

4. La experiencia se ha integrado directamente en el sistema.  Todos los problemas se han resuelto y tienen experiencia de una manera más amigable posible integrar en el sistema, al nuevo personal y los mejores consejos, en lugar de enterrados en otro lugar.

5. Diseño debe estar limpia y ordenada y unificada formato estandarizado.  Densa, de madera de estilo ensayo miraba preocupado bastante desagradable, no es fácil de solucionar problemas,.

6. petición de identificación único que utiliza varias palabras clave , las palabras clave resaltadas: tiempo, descriptiva de la entidad (por ejemplo VMName), nombres de operación.

Los pasos básicos para solucionar el problema:

Iniciar sesión en el servidor de aplicaciones -> Abrir Archivo de registro -> navegar a las ubicaciones de registro de errores -> según la orientación registros de errores claves para solucionar problemas, identificar problemas y resolver problemas.

donde:

1. Desde el rellano para abrir el archivo de registro.  Dado que más de un servidor de aplicaciones, iniciar la sesión para subir uno por uno para ver que no es conveniente. Necesidad de escribir una herramienta en la AG Ver todos los registros del servidor directamente en AG, o incluso directamente descartar al registro de errores es necesario.

2. Localizar la ubicación del registro de errores.  Actualmente ingrese disposición densa, fácil de navegar para el registro de errores. En general se puede utilizar en primer lugar de "tiempo" para localizar el registro de errores en la parte delantera del lugar, y luego usar la entidad palabra clave / nombre de la operación cerradura de combinación en el registro de errores. De acuerdo a localizar el registro de errores RequestID aunque más en línea con la tradición, pero en primer lugar encontrar RequestID, y no es descriptiva. Lo mejor es localizar directamente los lugares de registro de errores basado en palabras clave tiempo / contenido.

3. Analizar el registro de errores.  El contenido del registro de errores es la mejor manera de ser más sencillo, y el problema se características de la presente investigación es identificar claramente a ser coherente y dar pistas importantes.

Normalmente, el registro de errores problema es el contenido del registro es entender el contexto para el código actual, parece simple, pero siempre escritura incompleta, formato medio-Inglés; una vez que salga de la situación de código, es difícil saber exactamente lo que se dice, tienen que la gente piensa acerca o para ver el código con el fin de entender lo que es el significado del registro indica. Esto no es a sus propios pecados?

Por ejemplo:

if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)
                && (zone.hasStorageType(StorageType.io3) || zone.hasStorageType(StorageType.io4))) {
// 进入dfs1 和dfs2 在io3 io4 存储。
} else {
      log.info("zone storage type not support, zone: " + zone.getZoneId() + ", storageType: "
+ storageType.name());
      thrownew BizException(DeviceErrorCode.ZONE_STORAGE_TYPE_NOT_SUPPORT);
}

zona para apoyar el tipo de almacenamiento es correcta? no me dejan pienso!

registro de errores debe hacer:  incluso dejar el código en el contexto, y puede describir claramente lo que sucedió.

Además, si es capaz de explicar claramente los motivos directamente en el registro de errores, inicie sesión para hacer la inspección cuando se puede ahorrar más energía. En un sentido, el registro de errores también puede ser un documento muy útil, un registro de todo tipo de operación ilegal de casos de uso.

En la actualidad el contenido del registro de errores pueden ser los siguientes problemas:

1. registro de errores no indica los parámetros de error y contenido:

catch(Exception ex){
      log.error("control ip insert failed", ex);
      returnnew ResultSet<AddControlIpResponse>(
ControlIpErrorCode.ERROR_CONTROL_IP_INSERT_FAILURE);
}

No especificó la inserción de control de IP fallar. Si añadimos la palabra clave de control de IP, más fácil de buscar y error de bloqueo.

No son similares:

log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure.", e);

No especificó bajo las cuales IP de subred, que vale la pena señalar que, para identificarlos que hacer algo extra, puede afectar ligeramente el rendimiento. Esta compensación de tiempo de ejecución y depuración.

Solución: Uso String.Format ( "Algunos de los mensajes en ErrorObj:% s", errobj) Método indican los parámetros de error y contenidos.

Esto por lo general requiere la preparación de un método de objeto toString DO legible.

2. escenario de error no está claro:

log.error("nc has exist, nc ip" + request.getIp());

NC ya detecta un error en la createNc. Pero no especificó el registro de errores en la escena, las personas especulan por qué Carolina del Norte ha informado Existe un error.

Puede ser cambiado

log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());
log.error("[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());

No son similares:

log.error("not all vm destroyed, nc id " + request.getNcId());

cambio

log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s", vmNames, request.getNcId());

Solución: Un mensaje de error cuando se combina con las palabras, o añadir la interfaz de [nombre], indican el error antes de que las escenas de mensajes de error directamente desde el registro de errores saber para entender.

En general, capaz de conocer el ejecutor de la interfaz puede agregar [nombre], un servicio, más que las palabras.

3. El contenido no está claro, o desconocido su significado:

if(aliMonitorReporter == null) {
        log.error("aliMonitorReporter is null!");
} else {
       aliMonitorReporter.attach(new ThreadPoolMonitor(namePrefix, asynTaskThreadPool.getThreadPoolExecutor()));
}

leer:

log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx.");

No son similares:

if (diskWbps == null && diskRbps == null && diskWiops == null    && diskRiops == null) {
      log.error("none of attribute is specified for modifying");
      thrownew BizException(DeviceErrorCode.NO_ATTRIBUTE_FOR_MODIFY);
}

cambiado

log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);

Solución: más clara describe muy bien el contenido de error.

4. Solución de problemas contenido de la guía no está claro:

log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));

zkPath? cómo solucionar este problema? Quien debería ir? ¿Dónde encontrar más pistas específicas?

Solución: Añadir el conocimiento de fondo apropiado y que conducen las medidas de investigación.

El error no es específico y contenido detallado:

if (!ncResourceService.isNcResourceEnough(ncResourceDO,    vmResourceCondition)) {
      log.error("disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());
      thrownew BizException(ResourceErrorCode.ERROR_RESOURCE_NOT_ENOUGH);
}

Lo que no es exactamente suficientes recursos? La cantidad de excedente actual? ¿Cuántos ahora? Es de destacar que, para identificar a hacer algo adicional, puede afectar ligeramente el rendimiento. Esta compensación de tiempo de ejecución y depuración.

Solución: programa o mediante la mejora de habilidades, como las diferencias reveladas en la ubicación específica, reducir la alineación manual operativo.

6. media Inglés frase para que diga no es lo suficientemente clara para entender, necesidad de pensar de reconstruir el significado completo:

log.warn("cache status conflict, device id "+deviceDO.getId()+" db status "+deviceDO.getStatus() +", nc status "+ status);

leer:

log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc.", deviceDO.getId(), deviceDO.getStatus(), status));

Solución: el cambio de forma natural legible frase Inglés.

En resumen, el formato de registro de errores puede ser:

log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].");
log.error(String.format("[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].", params));

o

log.error("[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].");
log.error(String.format("[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].", parameters));

. [Probablemente la razón] [probable que tenga que hacer] puede omitirse en algunos casos, en algunas escenas e interfaces importantes explicar mejor.

Cada registro de errores es independiente, lo más completa posible, específica e instrucciones directas lo que salió mal en cualquier escenario, causada por qué razones, qué medidas o medidas a adoptar.

problema:

1.String.format afectará el rendimiento del juego que ingrese?

En general, el registro de errores debería ser relativamente pequeña, y la frecuencia de uso String.Format no sea demasiado alta, y no afectará el registro de aplicación.

2. El tiempo de desarrollo es muy tensa, las palabras que usted tiene tiempo para la discreción?

Establecer un formato estandarizado contenido, el contenido de juegos de formatos, puede guardar las palabras de tiempo de discreción.

3. Cuando de usar información, warn, error?

• información para la información de estado del programa normal de impresión debe aparecer, para facilitar el seguimiento de la ubicación;

• advierten muestran un sistema irracional ligero aparece, pero no afecta el funcionamiento y uso;

• error indica un error del sistema y excepción, incapaz de completar el operativo de destino normalmente.

El registro de errores es un medio importante para solucionar el problema. Al programar una característica que normalmente consideramos una variedad de errores que pueden ocurrir - y por qué:

Para solucionar el motivo correspondiente, que necesitamos para localizar la causa de algunos de los descripción de la tecla.

Esto formará un triple:

Síntoma -> error de clave de Descripción -> la última causa del error.

La necesidad de proporcionar una descripción del error apropiada para cada error crítico en la medida de lo posible, con el fin de localizar la causa del error apropiado.

En otras palabras, el tiempo de programación, a pensar cuidadosamente acerca de cuya descripción es muy beneficioso para localizar la causa del error, en la medida de lo posible agregar al registro de errores estas descripciones.