Fang und Protokollierung für irrelevante Operationen

8

Ich habe eine Methode, Timing-Informationen jeder Operation zu speichern:

%Vor%

Ich rufe die obige Methode nach jeder Operation auf. Was zählt, ist die Operation selbst, während das Timing nur eine Nebenaufgabe ist. Deshalb habe ich beschlossen, nichts zu tun, wenn die Methode fehlschlägt, außer sie zu protokollieren.

Aber mir wurde immer gesagt, dass das Protokollieren ohne die Ausnahme zu handhaben eine schlechte Übung ist. Also, wie soll ich den obigen Code umschreiben?

    
user1883212 21.09.2015, 11:10
quelle

4 Antworten

8

Wenn Sie die Konsequenzen kennen, d. h. der Aufruf timer.queue() könnte unterbrochen werden und die Daten nicht in eine Warteschlange stellen, und Sie können damit leben, dann ist es in Ordnung, die Ausnahme zu ignorieren. Wie bei den meisten Regeln müssen Sie wissen, wann sie zu brechen sind.

Allerdings würde ich Ihre Entscheidung mit einem Kommentar im catch-Block dokumentieren, so dass derjenige, der später den Code verwaltet, weiß, dass das Nichthandeln der Ausnahme kein Versehen war, sondern eine bewusste Entscheidung.

    
Thomas Stets 21.09.2015 11:17
quelle
5
  

Aber mir wurde immer gesagt, dass das Protokollieren ohne die Ausnahme zu verwalten eine schlechte Übung ist

Was bedeutet "verwalten"? Sie wiedersehen? Befolgen Sie die Schritte 1, 2, 3 blind, weil "zOMG eine Ausnahme ausgelöst wurde !! 111"?

Wenn Sie blindeste Best Practices und andere Arten von Ratschlägen befolgen, unabhängig von Ihrem Kontext, dann werden Sie wahrscheinlich mit wirklich problematischen und peinlichen Entscheidungen enden. Tu nichts, nur weil es die beste Übung ist. Bestätigen Sie die besten Praktiken, aber stellen Sie gleichzeitig sicher, dass sie in Ihrer Situation tatsächlich Sinn ergeben.

Fragen Sie sich selbst: Macht diese Ausnahme einen Unterschied? Verletzt es einen Vertrag? Ändert es den Ablauf Ihrer Anwendung? Wollen Sie das wirklich nicht und wenn, dann ist die Situation wirklich außergewöhnlich und Sie sollten wirklich damit irgendwie umgehen?

Wenn es keinen Unterschied macht und so weiter, dann ist es einfach akzeptabel, es einfach zu loggen. Es hängt wirklich von Ihrem Kontext und von der Bedeutung Ihrer Ausnahme ab.

LE: Natürlich, wie Thomas vorschlägt, möchten Sie vielleicht Ihre Entscheidung dokumentieren.

    
async 21.09.2015 11:37
quelle
4

InterruptedException ist speziell, weil es keinen Fehler signalisiert.

Wenn eine Methode eine InterruptedException deklariert, sagt sie, dass es sich um eine Blockierungsmethode handelt, die durch Unterbrechen ihres Threads abgebrochen werden kann. Brian Goetz erklärt :

  

Wenn eine Methode InterruptedException auslöst, sagt sie Ihnen Folgendes: if   Der Thread, der die Methode ausführt, wird unterbrochen   versuchen Sie zu stoppen, was es tut, und kehren Sie früh zurück und zeigen Sie es an   Frühzeitige Rückkehr durch InterruptedException. Braves Blockieren   Bibliotheksmethoden sollten auf Unterbrechung und Werfen reagieren   InterruptedException, damit sie innerhalb von abbrechbaren Aktivitäten verwendet werden können   ohne Kompromisse bei der Reaktionsfähigkeit.

Sie sollten entweder

  • Erhalte die Ausnahme nicht und füge einen throws InterruptedException hinzu
  • fang es auf, mach es sauber und fang es wieder auf
  • Wenn Sie es nicht werfen können (z. B. in Runnable ), rufen Sie Thread.getCurrentThread().interrupt();

Wenn Sie nur die Ausnahme verschlucken, beeinträchtigen Sie die Reaktionsfähigkeit Ihrer Anwendung.

    
wero 21.09.2015 11:53
quelle
0

Können Sie es wickeln und neu stricken? Und dann kann Ihr gewöhnlicher Ausnahmebehandler Protokollierung und Berichterstellung übernehmen. Und wenn möglich, stellen Sie einen Kontext dafür bereit.

    
bsingh 21.09.2015 11:18
quelle

Tags und Links