JDK8 CompletableFuture.supplyAsync la façon de traiter avec interruptedException

CompletableFuture.supplyAsync(
() -> {
    transporter.write(req);
    //here take the value from a blocking queue,will throw a interruptedException
    return responseQueue.take();
},  executorService);

La méthode commune pour traiter interruptedException est soit d'interrompre de nouveau ou directement jeter interruptedException, mais les deux ne peuvent pas travailler. Quelqu'un a l'idée?

"mais les deux ne peuvent pas travailler." => pourquoi?
les deux ont d'erreur du compilateur. si directe jeter l'exception, le compilateur va montrer exception non gérée, si l'attraper et de les appeler Thead.actuel.d'interruption, le compilateur va montrer doit retourner un T type.
Oui, vous avez besoin de retourner ou de le jeter. Si vous décidez de retourner la valeur null, par exemple: try { return queue.take(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return null; }
supposons que l'avenir représentent un calcul résultat qui est une valeur normale ou une exception, je pense qu'il devrait être un moyen de définir l'exception de l'avenir, il est mieux que le set null.
Je pense que les lambda fonctions ne prennent pas en charge de lever des exceptions afin de lancer une exception est hors de question. La seule chose que vous pouvez faire ici est de rendre quelque chose.

OriginalL'auteur GrapeBaBa | 2014-04-20

  1. 11

    - Je changer le code comme ceci.

        CompletableFuture<Rep> result = new CompletableFuture<>();
    CompletableFuture.runAsync(() -> {

        transporter.write(req);
        try {
            Rep rep = responseQueue.take();
            result.complete(rep);
        } catch (InterruptedException e) {
            result.completeExceptionally(e);
            Thread.currentThread().interrupt();
        } catch (Exception e) {
            result.completeExceptionally(e);
        }

    }, executorService);
    return result;
    Ce que vous avez fait est équivalente à la mienne. Hélas, CompletableFuture<Rep> result peut être remplacé par n'IMPORTE quelle classe qui est conforme à la "ou de" l'exception du paradigme. Par exemple, vous pouvez ajouter get, complete et completeExceptionally méthodes pour ResultWrapper et l'utilisation ResultWrapper rep = new ResultWrapper();. Il est tout à fait une coïncidence que vous avez rencontré cette fonction lambda limitation à l'aide CompletableFuture et encore vous l'avez résolu à l'aide de CompletableFuture, rendant l'utilisation de ces méthodes que vous avez utilisées.
    Oui,mais completablefuture a déjà l'abstraction pour calculer le résultat,donc je ne veux pas créer un nouveau type pour la même chose.
    Si vous travaillez avec d'autres personnes, cela peut embrouiller les lecteurs de votre code. Si pas, grand que cela a fonctionné pour vous.
    C'est parce que l'avenir et la promesse de deux concepts en un seul type completablefuture en java. De retour d'un completablefuture pu faire tout l'appel asynchrone en raison de il ya beaucoup de méthodes.
    CompletableFuture.runAsync utilisation n'est pas vraiment nécessaire ici, car vous n'utilisez pas de valeur de retour; si vous voulez économiser de cycles, vous pouvez créer ForJoinTask et de l'exécuter dans ForkJoinPool#commonPool. Ses un peu plus de code, mais vous devrez éviter de créer quelques occasions, et de l'écriture à la volatilité des champs, de sorte qu'il doit faire mieux.

    OriginalL'auteur GrapeBaBa

  2. 3

    Lambda fonctions ne prennent pas en charge de lever des exceptions, je pense que les développeurs Java aurez besoin d'un nouveau paradigme. Une chose qui vient à l'esprit est comme suit:

    public class ResultWrapper<R, E extends Exception> {
    E exception;
    R result;
}

    Lambda fonctions peuvent retourner les instances de ce wrapper. (Edit: votre cas)

    CompletableFuture<ResultWrapper<String, InterruptedException>> aFuture = ...;
...
aFuture.supplyAsync(
() -> {
    try {
        transporter.write(req);
    } catch(InterruptedException e) {
        ResultWrapper<String, InterruptedException> r = new ResultWrapper<>();
        r.exception = e;
        r.result = null;
        return r;
    }
    ...
},  executorService);
    Semble une solution
    S'il vous plaît marquer comme réponse si vous pensez que cela vous a aidé 🙂
    Au lieu de convertir des exceptions à une valeur de retour, vous devez envelopper dans un décoché exception et de les traduire pour un checked exception à l'extérieur si nécessaire. Garder des exceptions comme des exceptions, tout le chemin à travers. Les valeurs de retour sont réservées aux non-conditions d'erreur.
    Même si je suis d'accord dans une certaine mesure, considérer un producteur/consommateur scénario où produite/consommée objets sont lambda fonctions. Les consommateurs doivent attraper décoché des exceptions, car un producteur pourraient avoir jeté un décoché exception de la contrebande de sortir un checked exception. Vous ne savez pas lequel est le pire, c'est le Java qui suce, je suppose.
    Ne pas réinventer la roue.. Pour CompletableFuture.supplyAsync() l'envelopper dans java.util.concurrent.CompletionException et de la renvoyer.

    OriginalL'auteur mostruash

  3. 2

    J'ai couru dans la même question, mais après avoir lu plus de commentaires ici et ouvrage de référence, je pense que vous pouvez le faire soit l'un de ces deux:

    1 (ce que je fais):

    CompletableFuture.runAsync(() -> {
    transporter.write(req);
    try {
        Rep rep = responseQueue.take();
        result.complete(rep);
    } catch (Exception e) {
        throw new CompletionException(e);
    }
}, executorService);
return result;

    ou 2: 

    CompletableFuture<Rep> result = new CompletableFuture<>();
new Thread(()-> {
    transporter.write(req);
    try {
        Rep rep = responseQueue.take();
        result.complete(rep);
    } catch (Exception e) {
        retsult.completeExceptionally(e);
    }
}).start();

    Je sais que le 2ème ne pas utiliser le executorService, mais je sens le point de l'ensemble de l'aide CompletableFuture est l'utilisation du CompletionStage Api fonctionnelle de style.

    Votre deuxième solutions peuvent être améliorées. Voir stackoverflow.com/a/28961083/868941 pour le détail de l'explication.

    OriginalL'auteur derrdji