Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Improving error handling

Abierto
#15 15 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java
Área
observability-sre

Línea de trabajo

Comience revisando la API de FluentLogger y las rutas de error actuales descritas para los valores de retorno de log, las excepciones no gestionadas y las excepciones de búfer lleno. Compare los planes propuestos para el handler y para las excepciones de bloqueo, incluido el acceso a objetos Event no enviados empaquetados con mensajes. La tarea estará completa cuando exista un diseño acordado y un comportamiento definido de notificación de errores para las versiones 0.2.x.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I and @komamitsu san discussed how to improve error reporting of the current 0.2.x versions.

The major changes we considered are:

  • Add setHandler(handler) method to FluentLogger to accept an application-specific error handler.
  • In the error handler, provide a method for retrieving the remaining logs (the last one or all logs) that are not yet sent to fluentd.
  • The last logs are message packed Event objects. We need to provide a decoder so that the last log is meaningful to the user.

In this change, we should consider the following problem:

  • (Plan 1) A timing to report error. Currently errors can be reported in three ways: return value of log method (true or false), unmanaged exceptions or exceptions thrown when the buffer is full. If an error handler is added, log method should be non-blocking method, and the error must be handled in the user-defined error handler (in the subsequent code or in another thread). Does it the right choice?

Another option would be:

  • (Plan 2) Making log a blocking method and reporting errors by Exception rather than returning true or false. The last log event should be included in the thrown exception.

After writing this ticket, Plan 2 now looks simpler to me.
Any idea?

Lenguaje dominante
Java
Estrellas
210
Forks
86
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fluent/fluent-logger-java

Todos los issues de fluent/fluent-logger-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.