Stratégies de gestion des exceptions

Version imprimable

30/09/2014, 18h22
Anubis

Stratégies de gestion des exceptions

Bonjour tout le monde,

Je lance une petite discussions au sujet des différentes stratégies de gestion des exceptions qui peuvent être mises en place en Java.
C'est une problématique que je rencontre assez souvent.
J'aurai aimé avoir votre retour là-dessus et que vous veniez nous présenter les stratégies que vous avez vous-même mises en place.

Merci de vos contributions.

Pierre.
30/09/2014, 20h58
tchize_

qu'est-ce que tu entends par stratégie de gestion des exceptions?
01/10/2014, 08h12
Anubis

Ce que j'entends pas stratégie de gestion des exceptions est simplement lorsque tu développes une application et que tu rencontres une exception à gérer comment le fais-tu?
Qu'est ce qui fait que tu vas gérer l'exception immédiatement et qu'est ce qui fait que tu vas transmettre l'exception plus haut à ta méthode appelante (utilisation de throws dans la signature)?
Il y a également des stratégies auxquelles tu peux avoir pensé lors de la conception de ton application. Par exemple, toutes les classes d'exceptions propres à mon application hériteront d'une classe exception mère avec des fonctions prédéfini pour qu'elles respectent toutes les mêmes normes.
etc...

Tout ce qui peut constituer une stratégie, une norme, une bonne pratique...

Dis-moi si cela est plus clair avec ce complément d'information.
01/10/2014, 09h06
OButterlin

(de mon point de vue)

Les exceptions sont gérées à l'endroit où ça a un sens, trop de catch tue le catch et peut masquer des erreurs ;)

Prenons le cas d'une conversion chaîne en entier.
Dans la plupart des cas, tu vas mettre un try catch à l'endroit où tu convertis avec éventuellement une valeur par défaut si la conversion échoue.
Dans une classe de conversion JSF (par example), tu pourrais être amené à vouloir propager l'erreur de conversion... Tout ça pour dire que ce n'est pas évident d'établir des règles inscrites dans le marbre pour déterminer l'endroit où tu propages de l'endroit où tu catch...

Pour ce qui est de la structure des exceptions, j'utilise une exception nommée ValidationException qui contient une liste de CauseException pour faire et propager mes contrôles dans la couche métier.
Ce serait dommage de présenter à l'utilisateur les erreurs l'une après l'autre...

J'ai également créé une classe utilitaire qui convertit les causes en messages lisibles par l'utilisateur (en tenant compte de la Locale et des fichiers .properties bien sûr).

Du coup, le principe est le suivant : le contrôleur appelle la couche métier (EJB) et catch l'exception et la passe à la classe utilitaire.
01/10/2014, 10h29
Mister Nono

Bonjour,

Une méthodologie que j'ai adopté et qui fonctionne bien dans de très nombreux cas :

Quand une méthode soulève une exception, je la gère dans cette méthode car c'est là que l'on sait ce qui s'est passé et pourquoi.

Maintenant il n'est pas pertinent ou alors pertinent pour la méthode appelante qu'une exception ait été traitée. Comme la méthode qui gère sa propre exception ne le sait pas, je fais un "throw" de cette exception à la méthode appelante qui en fait que qu'elle veut : par exemple, elle prévient l'utilisation d'un soucis ou alors renvoi l'objet demandé quand même suivant le contexte...

Cela permet de faire une séparation entre la gestion de l'exception au plus tôt et ce que l'on fait quand une exception est traitée : une séparation de couche comme le préconise MVC. Maintenant si l'interface utilisateur doit changer, la partie métier et la partie modèle gèreront toujours leurs exceptions en interne.

A+ ;)
01/10/2014, 10h41
Anubis

Merci pour vos retours.

Citation:

Envoyé par Mister Nono

Maintenant il n'est pas pertinent ou alors pertinent pour la méthode appelante qu'une exception ait été traitée. Comme la méthode qui gère sa propre exception ne le sait pas, je fais un "throw" de cette exception à la méthode appelante qui en fait que qu'elle veut : par exemple, elle prévient l'utilisation d'un soucis ou alors renvoi l'objet demandé quand même suivant le contexte...

Je ne suis pas sur d'avoir bien compris ce que tu veux dire. Je me permet de le reformuler.
Lorsque tu as traité une exception dans une méthode tu génères une nouvelle exception que tu transmets à la méthode appelante pour qu'elle soit informé qu'il y a eu une erreur.
Est-ce bien ceci que tu voulais dire?

Bonne journée.
01/10/2014, 10h45
OButterlin
Citation:

Envoyé par Anubis

Lorsque tu as traité une exception dans une méthode tu génères une nouvelle exception que tu transmets à la méthode appelante pour qu'elle soit informé qu'il y a eu une erreur.

Non, il traite l'exception dans le catch et la renvoie (la même)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 try { ... un truc qui lance une exception ... } catch (Exception e) { System.out.print("J'ai une erreur dans la méthode blablabla... : " + e.toString()); throw e; }
01/10/2014, 10h59
Anubis
Citation:
Envoyé par OButterlin

Non, il traite l'exception dans le catch et la renvoie (la même)

Code:

1 2 3 4 5 6 7 8 9 10 11 12 try { ... un truc qui lance une exception ... } catch (Exception e) { System.out.print("J'ai une erreur dans la méthode blablabla... : " + e.toString()); throw e; }
C'est toujours dans le but d'informer la méthode appelante qu'une exception à eu lieu même si elle a été géré par la méthode appelé. Merci pour cette réponse, je vois mieux comment c'est techniquement fait.
01/10/2014, 11h23
adiGuba

Salut,

Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
Sinon il vaut mieux la laisser remonter...

Le tout couplé à un système de récupération des exceptions non-traité afin d'indiquer le problème a l'utilisateur et de remonter les infos de debug à l'équipe de développement (via un UncaughtExceptionHandler ou autre selon l'architecture).

Le problème c'est que les "checked-exceptions" de Java n'aide pas vraiment, en nous obligeant soit à les traiter (même si on ne sait qu'en faire) soit à les faire remonter explicitement (ce qui n'est pas toujours possible).
Du coup on est souvent obligé des les catcher pour les encapsuler dans une RuntimeException...

a++
01/10/2014, 11h38
OButterlin

Citation:

Envoyé par adiGuba

Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
Sinon il vaut mieux la laisser remonter...

C'est effectivement une bonne pratique, mais le problème vient parfois du fait que la façon de traiter dépend de l'endroit où elle se déclenche.
Je reformule ce que tu disais en :

on devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter de façon exhaustive

Tu es d'accord avec le postulat ou tu voyais autre chose ?

Pour la problèmatique "locale" du contexte de l'erreur, tu aurais une idée ?
01/10/2014, 11h50
adiGuba

Citation:

Envoyé par OButterlin

Pour la problèmatique "locale" du contexte de l'erreur, tu aurais une idée ?

Laisser remonter l'exception est amplement suffisant : on arrête tout.
Dans la majorité des cas il n'y a rien de mieux à faire...

Bien sûr il faut gérer proprement les ressources en les fermant proprement, et on pourrait mettre en place des "rollbacks" selon le cas, mais je ne considère pas cela comme une gestion de l'exception à proprement parler.

a++
01/10/2014, 11h57
OButterlin

Citation:

Envoyé par adiGuba

Laisser remonter l'exception est amplement suffisant : on arrête tout.
Dans la majorité des cas il n'y a rien de mieux à faire...

En pratique, c'est ce que je fais... mais j'aurais bien aimé un système adaptatif.

Bon, c'est certainement un faux problème, on peut faire plusieurs méthodes utilitaires pour centraliser des traitements/comportements différents
01/10/2014, 15h21
Anubis

Citation:

Envoyé par adiGuba

Salut,

Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
Sinon il vaut mieux la laisser remonter...
+

Mais si un exception qui ne semblait pas possible est remonté cela peut-être considéré comme un bug et que l'application n'est pas robuste.
Est-ce que toutes les exceptions qui peuvent être remonté ne devrait pas être prise en compte? Car si le développeur de la fonction lui fait remonter une exception c'est qu'elle peut arriver et donc qu'elle doit être traité, non?
Qu'en pensez-vous?

Cependant, j'aime bien l'idée d'un UncaughtExceptionHandler, qui permet de ne pas laisser une exception exploser littéralement à la tête de l'utilisateur.

A plus,

Pierre.
01/10/2014, 15h28
professeur shadoko

Citation:

Envoyé par adiGuba

Le problème c'est que les "checked-exceptions" de Java n'aide pas vraiment, en nous obligeant soit à les traiter (même si on ne sait qu'en faire) soit à les faire remonter explicitement (ce qui n'est pas toujours possible).
Du coup on est souvent obligé des les catcher pour les encapsuler dans une RuntimeException...

Hmmm... là il est difficile (pour moi) d'appréhender le problème dans sa généralité.
En principe on pourrait classifier les choses dans deux catégories:
- les exceptions "normales " relevant du fonctionnement "normal" de l'application. exemple: on dit que si on veut retirer trop d'argent sur un compte on claque une ExceptionDecouvert et là les exceptions controlées ("checked") sont du pain beni.
- les exceptions relevant d'un comportement anormal : bug -> NullPointerException; violation de contrat -> IllegalArgumentException etc... donc RuntimeException

En réalité il y a une "zone grise" qui enquiquine beaucoup c'est quand on a un problème de "service" genre IOException ... un défaut de service est-il un problème métier ou un bug? ah ... il parait que ça pose bien des problèmes de gestion d'exception (ça ne m'en a jamais posé mais je ne jurerai pas que ça ne m'arrivera pas un jour)... mais , pour commencer, la classification en deux catégories bien distinctes permet d'éclaircir les idées (même si dans certains cas on se retrouve avec des codes très génériques qui font throws Exception ... ce qui est un peu contradictoire avec quelques bons principes... mais bon ça ne m'empêche pas de dormir)
01/10/2014, 15h55
philou44300

Sur les projets sur lesquels j'ai été, voici ce qui était fait:
- Quand on utilise une méthode qui peut par exemple lever une IOException on l'entoure d'un try-catch. Dans le catch on logue une erreur et on throw une de nos propres exception (liée à la fonctionnalité de l'application) avec une catégorie qui correspond à l'endroit où s'est produit l'exception. Il y a un message et une solution possible par catégorie.
- Notre propre exception est remontée jusqu'au client afin qu'il y ait l'affichage du message correspondant (ex: l'import du fichier XML n'a pas marché et qu'il faut vérifier son contenu, qu'il est bien formé).
01/10/2014, 16h00
tchize_

Citation:

Envoyé par Anubis

Ce que j'entends pas stratégie de gestion des exceptions est simplement lorsque tu développes une application et que tu rencontres une exception à gérer comment le fais-tu?
Qu'est ce qui fait que tu vas gérer l'exception immédiatement et qu'est ce qui fait que tu vas transmettre l'exception plus haut à ta méthode appelante (utilisation de throws dans la signature)?

Alors je ne sais pas si on peux vraiment parler de stratégie, c'est souvent de la décision cas par cas:

Deux questions fondamentales à se poser sur l'exception: Est-ce que je sais en faire quelque chose? Est-ce qu'il est important d'en avertir l'appelant?

Si je sais en faire quelque chose (de cohérent j'entends pas juste log.error("Houla c'est le bordel ici")), je le fait.

Exemple: on me demande de contacter le LDAP pour retourner une liste d'utilisateur, le LDAP est mort, je suis capable de me rabattre sur le LDAP de backup, je le fait

Si je ne sais rien en faire, je ne joue pas à l'apprentit magicien

Exemple: on me demande de stocker un objet utilisateur sur une base de donnée, la connection avec le serveur de base de données est coupée, je vois pas trop quelle solution je pourrais apporter => on arrête les frais et on remonte.

Même si j'ai pu traiter le problème, si il est important d'avertir l'appelant, il est souvent préférable de lui lancer une exception plutôt que de lui retourner une valeur clé indiquant erreur. Car l'exception il devra en faire quelque chose, mais on a vite oublié que ça peut retourner erreur et juste balancer ça dans je ne sais quelle base de données comme une vraie valeur :)

Exemple: je dois télécharger un fichier .ODT sur une URL pour le convertir en PDF et le stocker sur le disque. L'URL me renvoie une IOException. Je peux traiter cette exception: fermeture du stream, arrêt de l'outil de convertion évenetuel, pas de création du PDF. Mais l'appelant a besoin de savoir que ca n'a pas été possible => je lui balance une exception de mon cru du style "ConversionFailed" parce que l'appelant il se fous de savoir que c'est du à un IOException ou un bug du converter.
01/10/2014, 17h39
adiGuba

Citation:

Envoyé par Anubis

Mais si un exception qui ne semblait pas possible est remonté cela peut-être considéré comme un bug et que l'application n'est pas robuste.

Raison de plus de remonter l'exception : cela permettra in fine d'avoir un rapport de bug.

Si tu traites l'exception sans savoir quoi en faire, tu risques de faire n'importe quoi ce qui engendrera in fine une autre exception...

Citation:

Envoyé par Anubis

Est-ce que toutes les exceptions qui peuvent être remonté ne devrait pas être prise en compte? Car si le développeur de la fonction lui fait remonter une exception c'est qu'elle peut arriver et donc qu'elle doit être traité, non?

Cela dépend de beaucoup de chose...
La quasi-totalité des méthodes peuvent remonter un NullPointerException. Est-ce que tu as des try/catch partout pour cela ???

Si tu ne sais pas comment traiter une exception, il n'y a pas de raison de le faire.
Autant la laisser remonter à l’appelant, qui se chargera de la traiter (ou pas).

Quitte à faire planter le programme/thread... mais un exception handler te permettra de récupérer les infos utile !

Citation:

Envoyé par professeur shadoko

Hmmm... là il est difficile (pour moi) d'appréhender le problème dans sa généralité.
En principe on pourrait classifier les choses dans deux catégories:
- les exceptions "normales " relevant du fonctionnement "normal" de l'application. exemple: on dit que si on veut retirer trop d'argent sur un compte on claque une ExceptionDecouvert et là les exceptions controlées ("checked") sont du pain beni.
- les exceptions relevant d'un comportement anormal : bug -> NullPointerException; violation de contrat -> IllegalArgumentException etc... donc RuntimeException

Le problème c'est que les checked-exception imposent ces catégorie sur le type de l'exception, alors que cette "zone grise" peut être assez large et qu'une même exception peut appartenir à une ou l'autre de ces catégorie, parfois même au sein d'une même méthode.

A l'inverse des unchecked-exceptions n'imposent rien, et l'on peut donc passer de l'une à l'autre selon notre besoin.

Sans compter que les checked-exception s'adapte mal et imposent de modifier les signatures, ce qui n'est pas forcément souhaitable ni possible.

a++
02/10/2014, 13h07
Anubis

Citation:

Envoyé par tchize_

Exemple: je dois télécharger un fichier .ODT sur une URL pour le convertir en PDF et le stocker sur le disque. L'URL me renvoie une IOException. Je peux traiter cette exception: fermeture du stream, arrêt de l'outil de convertion évenetuel, pas de création du PDF. Mais l'appelant a besoin de savoir que ca n'a pas été possible => je lui balance une exception de mon cru du style "ConversionFailed" parce que l'appelant il se fous de savoir que c'est du à un IOException ou un bug du converter.

Quand tu dis qu'il n'est pas important pour l'appelant de savoir que l'erreur du converter est du à une IOException ou un bug, je ne suis pas tout à fait d'accord. Afin de pouvoir informer l'utilisateur de manière pertinente il faut bien que l'application connaisse d'une manière ou d'une autre ce qui s'est passé.
Je trouve que c'est une très bonne idée d'utiliser une Exception du type "ConversionFailed" pour les erreurs concernant uniquement le Converter. Cela permet à l'appelant de ne pas avoir à gérer une multitude d'exceptions différentes qui peuvent être remonté par la méthode appelé. Cependant, je pense que cette exception générique doit encapsuler l'exception d'origine (ici, IOException) afin de ne pas perdre d'informations qui peuvent s'avérer précieuse pour l'utilisateur voire la personne en charge de la maintenance pour trouver une solution au problème.
02/10/2014, 13h48
tchize_

Citation:

Envoyé par Anubis

Quand tu dis qu'il n'est pas important pour l'appelant de savoir que l'erreur du converter est du à une IOException ou un bug, je ne suis pas tout à fait d'accord. Afin de pouvoir informer l'utilisateur de manière pertinente il faut bien que l'application connaisse d'une manière ou d'une autre ce qui s'est passé.

On est d'accord mais je peux très bien mettre cette information dans mon exception custom. Par exemple en chainant l'exception. Je peux aussi mettre ça dans les logs, ça fait partie du traitement local.

L'appelant (au sens de la méthode) se fous de savoir que le problème est une interruption de flux, un connection reset by peer, ou autre. L'information dont il a besoin c'est "le document n'est pas accessible". Eventuellement si on est sur un outil technique, "le document n'est pas accessible: http 503".

Quand je dis que l'appelant se fous de savoir que c'est une IOException j'entends pas là qu'il est inutile de la remonter. Aujourd'hui c'est une IOException parce que j'utilise les apis type URL / openConnection, demain ce sera une StreamException parce que j'aurais switché à un autre outils qui renvoie ce genre d'exception, etc. L'IOException est liée au choix technique d'utiliser des libriarie qui remontent ça. L'appelant s'en contre fou. Il dois savoir que la conversion n'a pas eu lieu et bien sur pourquoi (message).

Quand au ConversionFailed il peux se décliner autant que tu veux:

ConversionFailed -> ConversionReaderFailed, ConversionWriterFailed, etc.

On est sur de l'exemple en une ligne là dans ce que je donnais ;)
03/10/2014, 09h04
Anubis
Citation:

Envoyé par tchize_

On est d'accord mais je peux très bien mettre cette information dans mon exception custom. Par exemple en chainant l'exception. Je peux aussi mettre ça dans les logs, ça fait partie du traitement local.

L'appelant (au sens de la méthode) se fous de savoir que le problème est une interruption de flux, un connection reset by peer, ou autre. L'information dont il a besoin c'est "le document n'est pas accessible". Eventuellement si on est sur un outil technique, "le document n'est pas accessible: http 503".

Quand je dis que l'appelant se fous de savoir que c'est une IOException j'entends pas là qu'il est inutile de la remonter. Aujourd'hui c'est une IOException parce que j'utilise les apis type URL / openConnection, demain ce sera une StreamException parce que j'aurais switché à un autre outils qui renvoie ce genre d'exception, etc. L'IOException est liée au choix technique d'utiliser des libriarie qui remontent ça. L'appelant s'en contre fou. Il dois savoir que la conversion n'a pas eu lieu et bien sur pourquoi (message).

Quand au ConversionFailed il peux se décliner autant que tu veux:

ConversionFailed -> ConversionReaderFailed, ConversionWriterFailed, etc.

On est sur de l'exemple en une ligne là dans ce que je donnais ;)

Je ne l'avais pas compris ainsi. J'avais une autre vision de ta stratégie.
Je voyais la chose ainsi:
Code:

1 2 3 4 5 6 7 8 9 public void called() throws calledException{ try{ ... } catch(ExceptionHappened EH){ throw new CalledException("message", EH); } }
avec
Code:

1 2 3 4 5 6 7 8 9 public void caller(){ try{ called(); } catch(calledException){ manage the exception. } }
Ainsi l'appelant peut toujours accéder à l'historique de l'exception.
03/10/2014, 10h06
tchize_

c'est ce que je disais, on peux chainer l'exception ;)

et si les exceptions vous em...bètent

bon je n'ai pas pu résister au plaisir (pervers) du hack au sujet des exceptions (attention contient du java 8)

Code:

1
2
3
4
5
 
  @FunctionalInterface
public interface PeskyConsumer<X,T extends Throwable> {
    public void accept(X arg) throws T ;
}

Bon jusque là on a juste un Consumer qui a des problèmes d'exceptions

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
//d'accord il y a de l'abus ce n'est pas une interface mais une classe avec uniquement des méthodes statiques
public interface Teflon {
 
    public default <X, T extends Throwable> Consumer<X> teflonize(final PeskyConsumer<X,T> consumer) {
        return new Consumer<X>() {
            @Override
            public void accept(X t) {
                try {
                    consumer.accept(t);
                } catch (Throwable exc) {
                    Teflon.<RuntimeException>forgetThrowsClause(exc);
                }
 
            }
        } ;
 
    }
        public static <T extends Throwable> T forgetThrowsClause(Throwable t) throws T{
            throw (T) t;
        }
}

maintenant travaux pratiques :

Code:

1
2
3
4
5
6
7
 
// code  inutile (on pourrait directement appeler en "teflonizant") 
class PlasticArrayList<T> extends ArrayList<T> implements Teflon{
     public void forEachPesky(PeskyConsumer<T,?> pesk) {
            forEach(teflonize(pesk));
        }
    }

de plus en plus compliqué (sans augmentation du prix des places!)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
 @FunctionalInterface
public interface MayFail {
    public void check() throws Exception ;
}
 
public class PotentialFail implements MayFail{
    boolean fail ;
    static int num ;
    int number = num++ ;
 
    public PotentialFail(boolean fail) {
        this.fail = fail;
    }
 
    @Override
    public void check() throws Exception {
        System.out.println("call " +this);
        if(fail) {
            throw new Exception("failed" +this) ;
        }
 
    }
 
    public String toString() {
        return "PotentailFail " + number ;
    }
}
 
public class TestSneakyConsumer {
 
    public static void main(String[] args) {
        PlasticArrayList<PotentialFail> list = new PlasticArrayList<>() ;
        list.add(new PotentialFail(false)) ;
        list.add(new PotentialFail(true)) ;
        list.add(new PotentialFail(false)) ;
        try {
            list.forEachPesky(MayFail::check);
        } catch(Exception exc) {
            System.err.println("got Exception" +exc);
        }
    }
}

comme quoi: pourquoi faire simple quand on peut faire crade :aie: ?

05/10/2014, 15h10
tchize_

Attends là, j'ai bien lu, tu as sod***sé à sec le compilateur et la jvm en déguisant un Throwable quelconque en RuntimeException?

Je savais qu'il était possible de s'affranchir de l'obligation de catch dans la jvm, via des modifications du bytecode ou l'utilisation d'autres langages, mais pas que c'était possible juste en jouant avec les generic :ptdr:

Bravo! Tu as gagné le prix du pyscodepathe du mois :aie:
On commence comme ça et on fini par pondre du code pour ajouter dynamiquement des valeurs dans les enum ou pour construire un objet sans jamais appeler son constructeur :mrgreen:

Citation:

Envoyé par tchize_

On commence comme ça et on fini par pondre du code pour ajouter dynamiquement des valeurs dans les enum ou pour construire un objet sans jamais appeler son constructeur :mrgreen:

Je suis d'accord avec le fait qu'on souhaite parfois le retour de la sainte inquisition :roll:
en fait ce hack a été publié il y a 5 ans mais avec les objets de java.util.function on a un problème et là on peut (peut-être) faire un usage de ce truc qui ne nous garantisse pas une place en enfer ... voici , il me semble, un code, plus propre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 public class Cocoon { static <T extends Throwable> T forgetThrowsClause(Throwable t) throws T{ throw (T) t; } public static <X, T extends Throwable> Consumer<X> consumer(PeskyConsumer<X,T> peskyConsumer) throws T { return new Consumer<X>() { @Override public void accept(X t) { try { peskyConsumer.accept(t); } catch (Throwable exc) { Cocoon.<RuntimeException>forgetThrowsClause(exc) ; } } } ; } // etc, etc.. avec les principaux codes de java.util.function : Function, Supplier, ...
ici l'obligation de faire un catch est juste reportée d'un cran.

06/10/2014, 10h30
adiGuba
@professeur shadoko : je trouve qu'il y a quelques soucis avec ce "hack" :
- Cela cache le throw au compilateur, ce qui peut être gênant dans certains cas (le compilateur ne détecte pas la sortie de la méthode).
- Mais surtout on ne peut pas catcher l'exception simplement, car le compilateur va nous empêcher de faire un try/catch sur une checked-exception si elle n'est pas déclarée dans les méthodes...
Perso je préfère quand même les englober dans une RuntimeException, voir une exception perso avec une méthode fillInStackTrace() vide pour éviter le double stacktrace...

Par contre il est clair que les checked-exceptions deviennent (encore plus) une plaie avec les lambdas.

a++

reprenons le deuxième cas (Cocoon) : la méthode de masquage des exceptions n'est pas publique
on ne cache que provisoirement le catch au compilateur et l'exception remonte correctement
c'est comme si on disait: provisoirement j'ai une petite partie de code dans laquelle je ne peux retranscrire les clauses obligatoires (throws) mais :
- les exceptions vont remonter correctement (et interrompre un traitement si nécessaire)
- en bout de chaine je reinstalle l'obligation de faire un catch
Code:

1 2 3 4 5 6 7 8 9 10 try { /// try/catch obligé! Consumer<PotentialFail> cons = Cocoon.consumer(PotentialFail::check); list.forEach(cons); } catch(Exception exc) { System.err.println("got Exception" +exc); } // ici pas de try catch (toString est stupide : c'est juste pour montrer que le compilo n'exige pas de try/catch) Consumer<PotentialFail> cons = Cocoon.consumer(PotentialFail::toString); list.forEach(cons);
j'ai donc une zone de code dans laquelle je neutralise l'obligation de clause throws (parceque les librairies de fonction ne le prévoient pas) mais je remets les choses proprement (sans rajouter une RuntimeException d'emballage)
c'est un utilitaire à destination d'autres programmeurs

06/10/2014, 14h46
tchize_

Citation:

Envoyé par adiGuba

Par contre il est clair que les checked-exceptions deviennent (encore plus) une plaie avec les lambdas.

Le problème n'est pas selon moi les lambdas, mais surtout le fait qu'à aucun moment il semblerais, les apis stream n'aient envisagé qu'il puisse être vaguement possible qu'un machin de la chaine lance une exception :aie:

D'ailleurs, si je lance une RuntimeException dans un parallelStream, il se passe quoi? Est-ce que la spec précise quoi que ce soit à ce sujet? Les autres threads continuent de consommer, tout s'arrête? quoi? :mouarf:
06/10/2014, 15h56
adiGuba

Citation:

Envoyé par tchize_

Le problème n'est pas selon moi les lambdas, mais surtout le fait qu'à aucun moment il semblerais, les apis stream n'aient envisagé qu'il puisse être vaguement possible qu'un machin de la chaine lance une exception :aie:

Il peut tout à fait y avoir une exception dans un Stream... du moment que c'est une RuntimeException car l'API ne déclare pas d'exception.
(ou qu'on utilise un hack comme celui du professeur shadoko)

Le problème c'est uniquement cette limitation des checked-exceptions qui impose de déclarer les exceptions.
Il aurait fallut rajouter des "throws Exception" partout pour que cela puisse fonctionner avec des checked-exception, mais cela aurait eu l'effet pervers de devoir de trainer des try/catch partout même lorsqu'il n'y en a pas besoin !

Une autre solution envisagé à un moment consistait à faire évoluer l'API des Generics pour qu'elle puissent gérer proprement des exceptions en paramétrage... mais cela emmenait pas mal de soucis et de complexité...

Citation:

Envoyé par tchize_

D'ailleurs, si je lance une RuntimeException dans un parallelStream, il se passe quoi? Est-ce que la spec précise quoi que ce soit à ce sujet? Les autres threads continuent de consommer, tout s'arrête? quoi? :mouarf:

Ben il n'y a rien de particulier : le traitement est arrêté et tu reçois une exception.
Les autres threads sont bien sûr stoppé (mais sauf erreur c'est l'API ForkJoin de Java 7 qui doit gérer cela).

a++
06/10/2014, 16h39
professeur shadoko

est-ce qu'ici le problème n'est pas plutôt ce que fait l'agent situé dans le stream?
Si c'est un filtre le code devrait lui-même s'occuper de l'exception et retirer (ou invalider d'une certaine manière) l'objet coupable du stream ....
idée à demi-cuite: gérer alors un flot d'exceptions à part (j'ai un peu ça dans une gestion d'exception de démarrages de matériel: on essaye de démarrer tous les matériels qui sont indépendants les uns des autres et le code reçoit à la fin une Exception qui est en fait une séquence d'exceptions: le matériel A2 a ça, le matériel B5 a ça, le matériel C7 a ça , etc....- ce ne sont pas des "causes" au sens Java puisqu'on a des incidents indépendants qui sont collectés dans une même opération-)

Fuseau horaire GMT +2. Il est actuellement 21h10.