Fließender Try-Catch-Block [geschlossen]

Question

Ich habe viel von diesem Typcode in meiner App:

String authUserId = null;

try {
  authUserId = webTokenService.readUserIdFromToken(app.getMasterKey(), authToken);
} catch (Exception e) {
  // do nothing
}

Ziel ist es, bei jedem Fragment einen Wert zuzuweisen, wenn die Methode nicht ausgelöst hat, andernfalls null. Und obwohl der obige Code funktioniert, sieht er auf jeden Fall redundant und nicht vereinfacht aus.

Welche Java-Bibliothek kann diesen Code flüssiger machen? Mögen:

String authUserId = Try<String>.of(try -> {
   return webTokenService.readUserIdFromToken(app.getMasterKey(), authToken);
});

oder etwas einfacher.

AKTUALISIEREN:

Verwenden der Vavr-Bibliothek

<dependency>
  <groupId>io.vavr</groupId>
  <artifactId>vavr</artifactId>
  <version>0.10.3</version>
</dependency>

Gelöst mit:

String authUserId = Try.of(() -> webTokenService.readUserIdFromToken(app.getMasterKey(), authToken)).get();

Answer 1

Wenn Sie die Ausnahme vollständig schlucken, ist dies keine wirklich bewährte Methode . Es gibt einen schönen Artikel über Ausnahme von Baeldung:

Das Obige wird als Schlucken einer Ausnahme bezeichnet. Meistens wäre es für uns ein wenig gemein, dies zu tun, da das Problem dadurch nicht behoben wird und kein anderer Code das Problem beheben kann.

Ich habe eine Bibliothek gefunden , die dieses Verhalten implementiert. Es wurde jedoch seit einiger Zeit nicht mehr gewartet. Aus diesem Grund würde ich Vavr eher empfehlen . Die Ausnahme muss noch behandelt werden. Ein weiteres Tutorial ist auch bei Baeldung erhältlich . In der Dokumentation gibt es ein kleines Beispiel für die Aufteilung zweier Zahlen:

int divide(int dividend, int divisor) {
    return dividend / divisor;
}

Try<Integer> divide(Integer dividend, Integer divisor) {
    return Try.of(() -> dividend / divisor);
}

Answer 2

Angesichts der Tatsache, dass stilles Schlucken von Ausnahmen dumm ist, keine.

Es ist völlig trivial, so etwas selbst zu schreiben:

class ShootMyselfInLegToolkit {
    @FunctionalInterface
    public interface PermissiveSupplier<T> {
        T supply() throws Exception;
    }

    public <T> T ohMyLegs(PermissiveSupplier<T> supplier) {
        try {
            return supplier.supply();
        } catch (Exception itHurts) {
            return null; // dear lord.
        }
    }
}

Wenn Sie das wirklich in eine Bibliothek schieben wollen, auf jeden Fall.

Die etwas weniger albernen Funktionsbibliotheken funktionieren folgendermaßen: Sie geben sowohl einen (zulässigen - Java-eigenen jufSupplier kann dies nicht tun) Lieferanten als auch einen Ausnahmebehandler an. Es sieht also so aus:

Tool.tryGet(() -> Files.readAllLines(Paths.get("foo.txt")), ioex -> { code to handle the exception });

Sie können nicht einfach loslegen: Hey, keine Klammern, also drücke ich nie die Eingabetaste, und deshalb sind dies "weniger Codezeilen" und daher "einfacher", das ist ... nun, eine sehr seltsame Denkweise, die Sie haben Dort.

Was bedeutet in Ihren Worten "fließend" überhaupt? Ich erkenne den Begriff, der auf Setter, Getter und Builder-Methoden angewendet wird, und er bedeutet: "Kein get / set-Präfix". Das trifft hier offensichtlich nicht zu, also denken Sie klar, dass es etwas anderes bedeutet. Es ist nicht in der Java-Lang-Spezifikation, also vielleicht ausführlich.

Ich verstehe nicht, wie all diese Dinge einfacher zu verstehen oder leichter zu programmieren sind, abgesehen von albernen Kämpfen. Ich würde denken, die meisten würden zustimmen, dass die Einführung einer ganzen Reihe verrückter Bibliotheken NUR deshalb, weil Sie den in der Java-Community häufig verwendeten Stil abscheulich finden - das ist ein schlechter Ausweg. Das nicht-idiomatische Schreiben von Code ist eine schlechte Idee, unabhängig von der Sprache und davon, wie sehr Sie den allgemeinen Stil hassen. Verwenden Sie einfach eine andere Sprache oder passen Sie Ihren Stil an. Vielleicht leichter gesagt als getan, aber dennoch - bei weitem die bessere Idee.