Wie entscheidest du zwischen einer Checked und einer Unchecked Exception, und wie behandelst du Exceptions in einem Service?

Nimm eine Checked Exception nur dann, wenn der Aufrufer realistisch reagieren kann und du willst, dass der Compiler eine Entscheidung erzwingt; nimm Unchecked für Programmierfehler und für Fehler, die niemand weiter oben beheben kann. In der Praxis tendiert moderner Java-Code zu Unchecked, wobei Low-Level-Fehler in eine Domain-Exception mit Kontext gewrappt werden, die einmal an einer Grenze behandelt wird, etwa in einem Exception-Handler, der sie auf eine Response mappt.

Mein Test ist, ob ein Aufrufer damit etwas Sinnvolles anfangen kann. Eine vom Provider abgelehnte Zahlung ist ein legitimes fachliches Ergebnis, das ist also entweder eine Checked Exception oder, häufiger, ein Result-Typ. Ein null-Argument oder eine fehlgeschlagene Datenbankverbindung kann der aufrufende Code nicht beheben, das ist also Unchecked. In Services nehme ich überwiegend Unchecked Domain-Exceptions und wrappe die zugrunde liegende Ursache, damit der Stacktrace erhalten bleibt, und hänge die Identifier dran, die ich später im Log haben will, etwa die Order-Id, denn eine nackte SQL-Exception drei Schichten tiefer sagt mir nichts. Behandelt wird einmal, an einer Grenze: in Spring ist das ein Exception-Handler, der jede Domain-Exception auf einen Statuscode und einen Response-Body mappt, damit die Controller sauber bleiben. Wogegen ich mich im Review wehre: breit Exception fangen, fangen und loggen und dann weitermachen, als wäre nichts gewesen, und leere catch-Blöcke. Ich nutze außerdem überall try-with-resources statt finally-Blöcken, weil Suppressed Exceptions und Fehler beim Schließen damit gratis korrekt behandelt werden.