Wie soll ich mit aktivierten und nicht aktivierten Ausnahmen in der Java Config @Bean-Methode umgehen, um eine benutzerfreundliche Fehlerursache anzuzeigen?[Duplikat]

Question

Auf diese Frage gibt es hier bereits eine Antwort:

Anmutige Behandlung von Ausnahmen, die beim Erstellen von Beans ausgelöst werden (1 Antwort)

Geschlossen vor 4 Jahren.

Ich entwickle eine kleine Spring-Boot-basierte Befehlszeilenanwendung.Die Hauptklasse verfügt über ein @Autowired-annotiertes Feld @Autowired Repository repository; dessen Konstruktionsrezept in der Java-Config-Klasse bereitgestellt wird, die über eine entsprechende @Bean-annotierte Methode verfügt @Bean Repository repository(){...}.

Die @Bean-annotierte Methode enthält Code, der aktivierte und nicht aktivierte Ausnahmen auslösen kann.@Bean Repository repository(){...//exceptions}

Mein Ziel ist es, eine benutzerfreundliche Anwendung zu erstellen, die kurze Nachrichten auf der entsprechenden Protokollierungsebene protokolliert und nicht lange Stack-Traces.

Derzeit führt eine Ausnahme in der @Bean-annotierten Methode von Java Config dazu, dass die Anwendung mit beendet wird o.s.boot.SpringApplication: Application startup failed Nachricht und ein sehr langer Stack-Trace.

Ich frage mich, ob es eine gute Möglichkeit gibt, zumindest typische Ausnahmen (die mir bekannt sind) in der @Bean-annotierten Methode von Java Config zu behandeln, um benutzerfreundliche Kurzmeldungen zu protokollieren, die für die Fehlerbehebung nützlich sind.

Ich gehe davon aus, dass eine solche Strategie das Hinzufügen von Ausnahmebehandlungscode zur Java Config-Klasse voraussetzen würde, aber ich habe noch nie einen solchen Code in öffentlich verfügbaren Java Config-Klassen gesehen, was darauf hindeutet, dass Ausnahmebehandlungscode in Java Config-Klassen eine schlechte Praxis sein könnte.

Danke schön.

Answer 1

Ich denke, Sie haben hier mehrere Möglichkeiten, und welche die beste ist, hängt weitgehend von Ihren persönlichen Vorlieben und der Struktur Ihrer Bewerbung ab.

Eine Möglichkeit wäre, vor dem Anruf die gesamte Eingabevalidierung durchzuführen SpringApplication.run().Dies würde für alle Befehlszeilenargumente funktionieren, wäre aber bestenfalls für alles, was über konfiguriert wurde, umständlich application.properties.

Anstatt Ausnahmen von Ihrem auszulösen @Bean Mit diesen Methoden könnten Sie sie erkennen und entsprechend behandeln.Wenn das Problem geringfügig ist, können Sie eine Info- oder Warnmeldung protokollieren, die das Problem erläutert, und die Fortsetzung der Anwendung zulassen.Wenn das Problem katastrophal ist, können Sie eine Fehlermeldung protokollieren und dann anrufen System.exit().Dies bietet zwar eine benutzerfreundliche Fehlerberichterstattung für alle Ausnahmen, die während Ihres Aufenthalts ausgelöst werden @Bean Wenn Methoden aufgerufen werden, verbleiben weiterhin Stack-Traces für alle danach auftretenden Ausnahmen.

Zuletzt könnten Sie den Anruf auf abschließen SpringApplication.run() in einem Try-Catch-Block.Anschließend können Sie die abgefangene Ausnahme und die Ursachenkette untersuchen, um eine geeignete Fehlermeldung für die Protokollierung zu ermitteln.Der Vorteil dieses Ansatzes besteht darin, dass Sie für jede verursachte Ausnahme eine benutzerfreundliche Fehlermeldung bereitstellen können SpringApplication.run() scheitern, nicht nur einer, der aus deinem Inneren geworfen wird @Bean Methoden.

Vorausgesetzt, es gibt Befehlszeilenargumente zur Validierung, würde ich wahrscheinlich eine Kombination aus der ersten und dritten Option verwenden.Als erstes würde ich eine CLI-Bibliothek wie JOpt Simple verwenden, um die Sache etwas einfacher zu machen.