Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improving error handling

Aperta
  • Qualcosa non va?
#15 15 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
java
Ambito
observability-sre

Direzione di ricerca

Iniziare esaminando l’API FluentLogger e gli attuali percorsi di errore descritti per i valori restituiti da log, le eccezioni non gestite e le eccezioni di buffer pieno. Confrontare i piani proposti per l’handler e per le eccezioni di blocco, incluso l’accesso agli oggetti Event non inviati e contenenti messaggi. Il lavoro sarà completato quando saranno stati concordati un design e un comportamento definito per la segnalazione degli errori nelle versioni 0.2.x.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Java
Stelle
210
Fork
86
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di fluent/fluent-logger-java

Tutte le issue di fluent/fluent-logger-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.