Publicité

Affichage des résultats du sondage: Êtes-vous pour ou contre cette proposition ?

Votants
385. Vous ne pouvez pas participer à ce sondage.
  • Pour

    334 86,75%
  • Contre

    51 13,25%
+ Répondre à la discussion
Page 7 sur 9 PremièrePremière ... 3456789 DernièreDernière
Affichage des résultats 121 à 140 sur 171
  1. #121
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 211
    Points : 19 183
    Points
    19 183

    Par défaut

    Citation Envoyé par mavina Voir le message
    On en revient au même problème, si j'écris
    Code :
    1
    2
    3
    4
    catch(SQLException | IOException e)
    {
        System.out.println(e.getSQLState());
    }
    Celà ne compile tout simplement pas ? Celà signifie donc que le compilateur doit vérifier à chaque fois si les exceptions catchées en groupe sont "compatibles" pour l'appel de telle ou telle fonction ?

    Donc si je veux faire ca je dois traiter séparément mes exceptions, même si hormis le SQLState je fais exactement le même traitement sur mes exceptions ?
    Comme je l'ai dit l'intérêt de cela est de permettre d'éviter de multiplier les try/catch identique avec un code générique. Si tu utilises getSQLState() tu sors du traitement commun et c'est normal que tu utilises un catch spécifique : cela ne rentre pas dans le cadre de cette proposition.

    Citation Envoyé par pcaboche Voir le message
    C'est ça ?
    Oui. Enfin c'est comme cela que je le comprend.


    Citation Envoyé par pcaboche Voir le message
    Dans ce cas, alors, pourquoi ne pas étendre le principe à d'autres types de variables que les exceptions ? Comme ceci :
    Je vois déjà nettement moins le besoin de cela... si on a besoin de faire des traitement si spécifique on peut utiliser instanceof :
    Code :
    1
    2
    3
    4
    5
    6
    7
    if (maVariable instanceof Ta) {
        Ta a = (Ta) maVariable;
        // ...
    } else if (maVariable instanceof Tb) {
        Tb b = (Tb) maVariable;
        // ...
    }
    a++

  2. #122
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Comme je l'ai dit l'intérêt de cela est de permettre d'éviter de multiplier les try/catch identique avec un code générique. Si tu utilises getSQLState() tu sors du traitement commun et c'est normal que tu utilises un catch spécifique : cela ne rentre pas dans le cadre de cette proposition.
    Dans ce cas la syntaxe utilisée est ambigüe.

    Code java :
    1
    2
    3
    4
    5
     
    catch(SQLException | IOException e)
    {
        e.printStackTrace();
    }

    Lorsqu'on lit le code, on ne sait pas trop quel est le type de "e" (ce qui est embêtant pour un langage fortement typé):

    - Est-ce que "e" est de type IOException ?
    - Est-ce que "e" est soit de type IOException soit de type SQLException ?
    - Est-ce que "e" est d'un autre type (Exception, Ancetre commun) ?

    Je suis du même avis qu'un intervenant précédent pour utiliser une syntaxe plus claire:
    Code java :
    1
    2
    3
    4
    5
     
    catch(Exception e: SQLException,IOException)
    {
           e.printStackTrace();
    }

    La c'est clair que "e" est du type Exception.
    C'est également clair que la classe de "e" est une SQLException ou une IOException.
    Le compilateur peut facilement vérifier au moment de la compilation si les type listés sont bien des sous-classes de Exception.


    En plus ca reste cohérent avec la syntaxe actuelle:
    Code java :
    1
    2
    3
    4
    5
     
    catch(Exception e  /*: SQLException,IOException */)
    {
           e.printStackTrace();
    }
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #123
    Membre du Club
    Inscrit en
    avril 2003
    Messages
    77
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 77
    Points : 68
    Points
    68

    Par défaut le principe est bon

    Par contre, je préfère que ce soit une virgule au lieu de la barre verticale.

  4. #124
    Invité de passage
    Inscrit en
    février 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 4
    Points : 4
    Points
    4

    Par défaut

    Contre.
    En fait pas contre cette proposition particulière mais contre l'apparition d'un tas de syntaxe alternatives qui ne seront pas maitrisées par tout le monde et risque de rendre le code immaintenable. Pour avoir eu à maintenir du code Perl, le principe de pouvoir faire la même chose de 100 façon différente n'est pas une très bonne idée.
    Après si on conserve les gardes fous nécessaire alors "pourquoi pas".

  5. #125
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 268
    Points
    268

    Par défaut Pas encore décidé

    Simplifier les catchs serait un plus, mais pbm pour la syntaxe (je ne suis pas original )

    A la limite avec une virgule. Je n'aime pas l'idée d'ajouter des symbole | ou : dans la syntaxe de déclaration Java, qui sont plus des symbole d'opérateurs.
    Ca ferait tendre le langage un peu plus vers C++, et le rendrait moins accessible.

    entre parenthèses, le catch(Exception ) n'est pas une alternative viable, il ne faut jamais catcher les exceptions qui n'ont pas à l'être (notamment les Runtime)

    Juste pour rire, j'ai pensé à une syntaxe generics:
    Code :
    1
    2
    3
    4
    5
    6
    7
     
    try{
      //mon truc qui lance des exceptions.
    }catch <T extends Exception super IOException, SQLException>  (T e){
      System.out.println("c'est tout planté");
      return;
    }
    Vous en pensez quoi?

    à ne pas prendre trop sérieusement.
    edit: le super n'est pas vraiment correct, puisqu'en fait on "étend" de l'un, ou de l'autre, bref, c'était juste pour faire ressembler à du générique.

  6. #126
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 376
    Points : 35 146
    Points
    35 146

    Par défaut

    Pour le regroupement, avec précision de l'ancêtre à utiliser. Après avoir, dans une application écrit trois ligne de code dans une méthode puis avoir demandé à mon IDE d'auto générer les catch et terminé avec deux couches imbriquées de try catch finally et une 12aine d'exceptions levée (et oui, quand vous jouez avec des transactions c'est très vite verbeux!) sans possibilité d'ancêtre commun (ceux qui avaient la cahnce d'avoir un ancêtre commun avaient des traitement différents), j'ai terminé avec 3 ligne de buisness code, une 20 aines de lignes de buisness code "nettoyage en cas de problème" et pas moins du reste des 2 pages en code dupliqué / try catch à tout va.


    Mais, contre, l'utilisation du |, pour une raison pragmatique, ce caractère nécessite une gymnastique à 2 mains et avec la touche alt-gr sur les claviers belge, alors que la virgule se tappe à une seul doigt Et aussi eu égard au fait que la notation ',' est cohérente avec la notation utilisé en déclaraction de méthode (throws x,y,z) -> catch x,y,z
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  7. #127
    Membre confirmé
    Avatar de JHelp
    Inscrit en
    octobre 2002
    Messages
    185
    Détails du profil
    Informations forums :
    Inscription : octobre 2002
    Messages : 185
    Points : 277
    Points
    277

    Par défaut

    Pour, avec la syntaxe d'Uther :

    Citation Envoyé par Uther Voir le message
    Code :
    1
    2
    3
    ...
    catch (Exception e : InstantiationException, IllegalAccessException){
    ...
    Apres , ou | je n'ai pas d'avis. Les deux ce justifient et aucun ne me choque.

    JHelp
    Pour avoir une réponse efficace :
    1) Soyez précis dans vos questions
    2) Choisssez bien votre forum
    3) Consultez la FAQ et la doc avant

  8. #128
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 712
    Points : 6 304
    Points
    6 304

    Par défaut

    Pour, pour, pour et encore pour!
    Je reprend cet exemple :

    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
     
        try
        {
          Class clazz = Class.forName("org.berkeley.Database");
          Constructor constructor =
            clazz.getConstructor(String.class, String.class, String.class);
          return constructor.newInstance(url, username, password);
        }
        catch (InstantiationException e)
        {
          throw new PluginException(e);
        }
        catch (IllegalAccessException e)
        {
          throw new PluginException(e);
        }
        catch (IllegalArgumentException e)
        {
          throw new PluginException(e);
        }
        catch (InvocationTargetException e)
        {
          throw new PluginException(e);
        }
        catch (NoSuchMethodException e)
        {
          throw new PluginException(e);
        }
        catch (SecurityException e)
        {
          throw new PluginException(e);
        }
        catch (ClassNotFoundException e)
        {
          throw new PluginException(e);
        }

    Après cela donne :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
        try
        {
          Class clazz = Class.forName("org.berkeley.Database");
          Constructor constructor =
            clazz.getConstructor(String.class, String.class, String.class);
          return constructor.newInstance(url, username, password);
        }
        catch (InstantiationException | IllegalAccessException | IllegalArgumentException | InvocationTargetException | NoSuchMethodException | SecurityException | ClassNotFoundException e)
        {
          throw new PluginException(e);
        }
    Et là nous sommes dans un cas ou la gestion de l'exception représente une seule ligne de code! Ce serait marrant si c'était 2-3 voire 10 lignes de codes.

    Sérieusement, cette proposition fait partie de mes favorites.

  9. #129
    Invité régulier
    Inscrit en
    juillet 2008
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 8
    Points : 7
    Points
    7

    Par défaut

    Que sera le type de e dans
    Code :
    1
    2
    3
    4
    5
    try {
        return klass.newInstance();
    } catch (InstantiationException | IllegalAccessException e) {
        throw new AssertionError(e);
    }
    ?


    J'ai peur que cette syntaxe ne mène à des choses étranges et difficiles à comprendre. Pour cette raison, je serais plutot contre, utiliser une classe mère qui englobe tout ce que l'on veut traiter me semble être la seule façon propre de faire ce genre de chose, simplement à cause du problème de typage de l'exception traitée dans le bloc.

    Dans
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    try
        {
          Class clazz = Class.forName("org.berkeley.Database");
          Constructor constructor =
            clazz.getConstructor(String.class, String.class, String.class);
          return constructor.newInstance(url, username, password);
        }
        catch (InstantiationException | IllegalAccessException | IllegalArgumentException | InvocationTargetException | NoSuchMethodException | SecurityException | ClassNotFoundException e)
        {
          throw new PluginException(e);
        }
    Quelle implémentation du constructeur de PluginException est donc appelée ?

  10. #130
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 712
    Points : 6 304
    Points
    6 304

    Par défaut

    Code :
    1
    2
    3
    4
    5
    try {
        return klass.newInstance();
    } catch (InstantiationException | IllegalAccessException e) {
        throw new AssertionError(e);
    }
    Le type de e? Sans doute exception ou throwable. Avec un instanceOf on pourrait connaître et caster e dans son type véritable.

  11. #131
    Membre Expert
    Avatar de mavina
    Homme Profil pro Frédéric Mora
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric Mora
    Âge : 29
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 346
    Points
    2 346

    Par défaut

    Citation Envoyé par _skip Voir le message
    Code :
    1
    2
    3
    4
    5
    try {
        return klass.newInstance();
    } catch (InstantiationException | IllegalAccessException e) {
        throw new AssertionError(e);
    }
    Le type de e? Sans doute exception ou throwable. Avec un instanceOf on pourrait connaître et caster e dans son type véritable.
    Ok, donc les lignes que tu gagnes dans la proposition tu les perds en tests d'instance...

    Comme disait un illustre prof d'info de DUT : "Et voici une belle preuve de la théorie de conservation des emmerdements!"

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  12. #132
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 376
    Points : 35 146
    Points
    35 146

    Par défaut

    Pour avoir écrit du code de traitement d'erreur, dans lequel tu catch 10 exceptions de nature différentes, pour mettre exactement le même code dedans (et je plaisante pas, c'est du log, de la mise en valeur par défaut et du retour, soit en moyenne 5 lignes dupliquées à chaque fois), c'est chiant, illisible et surchargé! Et pour ceux qui disent 'on peut faire un catch sur le type parent commun c'est la même chose...', NON! Ce n'est absolument pas la même chose. Un catch sur le parent commun catch *aussi* ce qu'on ne veux pas catcher, ce qui fait qu'on va quand meme se tapper une tartine de test en dessous pour tout filter et faire des throw de ce dont on avait pas besoin.

    Par contre la forme ne me plait pas, elle ne permet pas de typer spécifiquement e, qui peut dans certains cas etre une RuntimeException, dans d'autre une Exception, dans d'autres cas un Throwable.... A l'auteur de décider je trouve.

    Le but de ce code n'est pas de faire des catch ou il faut se comporter différement suivant le type, le but est de regrouper les catchs dont le code est identique et pour lequel un type d'exception commun est utilisable, mais ou on ne veux *pas* catcher Tout ce qui correspond au type commun (exemple, on veux catcher 6 RuntimeException)
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  13. #133
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 712
    Points : 6 304
    Points
    6 304

    Par défaut

    Citation Envoyé par mavina Voir le message
    Ok, donc les lignes que tu gagnes dans la proposition tu les perds en tests d'instance...

    Comme disait un illustre prof d'info de DUT : "Et voici une belle preuve de la théorie de conservation des emmerdements!"

    F.
    Mais non t'as pas compris!
    Je disais juste que le type véritable de e serait celui de l'exception qui a été levée.
    Je pense que mon premier post avec l'exemple des PluginException montre bien l'intérêt d'une telle chose. Sinon on fait un catch(Exception) et on supprime n'importe quelle erreur ce qui est une bêtise.
    D'ailleurs c'est hors sujet mais j'ai toujours trouvé le concept de checked exceptions RI-DI-CU-LE.

  14. #134
    Membre Expert
    Avatar de mavina
    Homme Profil pro Frédéric Mora
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric Mora
    Âge : 29
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 346
    Points
    2 346

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    Pour avoir écrit du code de traitement d'erreur, dans lequel tu catch 10 exceptions de nature différentes, pour mettre exactement le même code dedans (et je plaisante pas, c'est du log, de la mise en valeur par défaut et du retour, soit en moyenne 5 lignes dupliquées à chaque fois), c'est chiant, illisible et surchargé! Et pour ceux qui disent 'on peut faire un catch sur le type parent commun c'est la même chose...', NON! Ce n'est absolument pas la même chose. Un catch sur le parent commun catch *aussi* ce qu'on ne veux pas catcher, ce qui fait qu'on va quand meme se tapper une tartine de test en dessous pour tout filter et faire des throw de ce dont on avait pas besoin.

    Par contre la forme ne me plait pas, elle ne permet pas de typer spécifiquement e, qui peut dans certains cas etre une RuntimeException, dans d'autre une Exception, dans d'autres cas un Throwable.... A l'auteur de décider je trouve.

    Le but de ce code n'est pas de faire des catch ou il faut se comporter différement suivant le type, le but est de regrouper les catchs dont le code est identique et pour lequel un type d'exception commun est utilisable, mais ou on ne veux *pas* catcher Tout ce qui correspond au type commun (exemple, on veux catcher 6 RuntimeException)
    Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction, ce qui facilitait une éventuelle mise à jour / un éventuel débug du code dupliqué (qui ne l'aurait plus été).
    Je trouve que cette proposition n'apporte rien ou pas grand chose, mise à part qu'on se demande ce qui va être retourné, ce qui va être catché ou pas, etc etc

    Citation Envoyé par _skip Voir le message
    Mais non t'as pas compris!
    Je disais juste que le type véritable de e serait celui de l'exception qui a été levée.
    Je pense que mon premier post avec l'exemple des PluginException montre bien l'intérêt d'une telle chose. Sinon on fait un catch(Exception) et on supprime n'importe quelle erreur ce qui est une bêtise.
    D'ailleurs c'est hors sujet mais j'ai toujours trouvé le concept de checked exceptions RI-DI-CU-LE.

    C'est bien ce que je dis : sans instanceof, impossible de savoir ce qui a été catché, donc tu en reviens à tester le type de l'excaption apres l'avoir catchée juste pour gagner 3 catch...

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  15. #135
    Invité régulier
    Inscrit en
    juillet 2008
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 8
    Points : 7
    Points
    7

    Par défaut

    A mon humble avis, si on veut effectuer le même traitement sur toutes les exceptions que rassemblera cette syntaxe (celle-ci ou une approchante), il va bien falloir trouver un contrat fonctionnel commun à toutes ses exceptions parce que ce sera au final ce que l'on devra manipuler dans le bloc de traitement commun : un truc sur lequel il faudra faire des choses...

    Ce que l'on pourra faire comme "trucs" sur cette "chose" dépendra de sa nature... et donc de son type. Il me semble que l'on est donc ramené à trouver un type commun à toutes ces exceptions que l'on rassemble dans cette écriture et donc on est ramené à l'héritage (de type), ce que Java sait déjà faire.

    Je me méfie terriblement des facilités d'écriture qui rendent les choses ou moins claires, ou moins lisibles, ou ajoutent encore de la complexité à ce qu'il est souvent préférable de garder un peu verbeux mais au combien plus simple et sans ambiguité.
    Quelques secondes de moins à écrire, une vie d'emmerdes en maintenance...

  16. #136
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 712
    Points : 6 304
    Points
    6 304

    Par défaut

    Je ne suis pas d'accord avec vous, il m'arrive très souvent de vouloir réagir à une exception sans pour autant avoir besoin d'informations spécifiques sur l'exception elle-même.

    Neuf fois sur dix je me fiche du type de l'exception, je veux juste la catcher pour pouvoir nettoyer derrière moi (par ex : déclencher un rollback) puis ensuite la propager.
    Donc ce fameux code de rollback qui se situe dans le bloc catch et qui n'est pertinent que dans le contexte de cette méthode, ça me coûte personnellement de le sortir dans une fonction car si je commence à faire ça je vais avoir autant de méthodes non-réutilisables qui gèrent des exceptions que de méthodes métiers.

    Donc la solution actuellement c'est le copier-coller, ce qui n'est pas super. Là ce serait l'occasion d'avoir une véritable solution.

  17. #137
    Membre régulier
    Profil pro
    Développeur Java
    Inscrit en
    août 2007
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 57
    Points : 77
    Points
    77

    Par défaut

    J'ai mis pour car l'idée n'est pas foncièrement mauvaise, même si la syntaxe a un peu trop l'air d'une expression booléenne à mon goût.

    Mais bon, beaucoup d'applications ont des exception "maison" qui donnent souvent des choses de ce style :
    Code :
    1
    2
    3
    4
    5
    try{
        //mon super code
    } catch (Exception e){
        throw new MonExceptionTechnique(e);
    }
    où il n'est pas très important de savoir quel type d'exception a été remontée (car elles ne devraient de toute façon jamais arriver ).

  18. #138
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 376
    Points : 35 146
    Points
    35 146

    Par défaut

    Citation Envoyé par mavina Voir le message
    Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction,
    La notion de facile est relativement gratuite sans connaitre les détails.
    Si ce bloc catch doit manipuler au moins 5 variables différentes, il faudra les passer ladite fonction, pour la lisibilité çà se complique déjà. Ensuite si ta méthode au final ressemble à


    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
    public UnType maMethode(machin, truc, bidule, chouette) {
    ...
       Blabla blabla = null;
       Blabla blabla2 = null;
       try{
           blabla  = machine.unTruc(truc.bazar(bidule), chouette);
       } catch (ExceptionType1 e){
           traiteMaMathodeException(e);
       } catch (ExceptionType2 e){
           traiteMaMathodeException(e);
       } catch (ExceptionType3 e){
           traiteMaMathodeException(e);
       } 
     
       try{
           blabla2  = machine.unAutreTruc(truc.bazar(bidule), chouette);
       } catch (ExceptionType1 e){
           traiteMaMathodeException2(e);
       } catch (ExceptionType2 e){
           traiteMaMathodeException2(e);
       } catch (ExceptionType3 e){
           traiteMaMathodeException2(e);
       } 
    ...
    }
    Je vois plusieurs problèmes à ces fonctions de traitement d'erreur:
    1) elle ne peuvent pas décider conditionnellement si oui ou non il faut poursuivre le traitement (ex: exception && chouette !=null -> on poursuit avec blabla=chouette.getChose())
    2) elle ne peuvent pas, en cas de poursuite, changer plusieurs variables locales au bloc appelant (faire sauter un for d'un cran, utiliser une valeur par défaut avant la poursuite du traitement, effectuer un break; du for (note je sais pas si c'est autorisé dans un catch çà). Exemple simple, dans une exception précise sur les transaction de la db, il faut passer par une nouvelle transaction locale à la méthode, noter dans une variable locale qu'on est en transaction locale pour nettoyage dans le finally, çà fait 2 variables à manipuler.
    3) il est difficile de leur donner des noms explicite et elles pulluleraient vite.
    4) si t'as 10 méthodes objet qui ont deux groupes d'exception à gérer chacune (deux blocs try/catch), çà te rajoute 20 méthodes au noms par toujours net :/
    6) pour 5 lignes dans le catch répétées 10 fois dans un try, tu passe de 6 lignes de code (catch + 5 lignes ) à 2 lignes de code, çà t'en fait encore 20 (2*10), alors qu'un catch générique aurait eu seulement 7 lignes (je met les catch générique en 2 lignes, parce que bon, 10 exception, on peut bien les mettre sur 2 lignes :p)

    En pratique, si je me suis retrouvé avec des lignes dupliquées dans mes catch, c'est clairement par choix, c'était la moins mauvaise solution.... Alors un truc qui me permettrait d'éclaircir un code si je devais tomber à l'avenir sur ce genre de joyeuseté une nouvelle fois, je suis preneur
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

  19. #139
    Membre éprouvé Avatar de djsnipe
    Inscrit en
    mai 2008
    Messages
    440
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 440
    Points : 440
    Points
    440

    Par défaut

    Et pourquoi ne pas introduire une sur classe d'Exception particulière, qui ait le rôle de représenter toutes les exceptions non runtime pouvant être lancées par le bloc try ?

    Ce ne serait finalement pas la seule exception un peu particulière, vu que les RuntimeException existent et on un comportement particulier. Et ça évite d'introduire toute nouvelle syntaxe dans le langage (même si certaines des propositions du topic me conviendraient aussi).

  20. #140
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 376
    Points : 35 146
    Points
    35 146

    Par défaut

    Citation Envoyé par djsnipe Voir le message
    Et pourquoi ne pas introduire une sur classe d'Exception particulière, qui ait le rôle de représenter toutes les exceptions non runtime pouvant être lancées par le bloc try ?

    Ce ne serait finalement pas la seule exception un peu particulière, vu que les RuntimeException existent et on un comportement particulier. Et ça évite d'introduire toute nouvelle syntaxe dans le langage (même si certaines des propositions du topic me conviendraient aussi).
    je vois plusieurs problème:

    1) les exceptions qu'on voudrait grouper ne doivent alors pas implémenter runtimeException, c'est pas toujours le cas, sourtout quand on hérite de libs tierces sur lesquelles on a peu de controlle
    2) çà casse les notions d'héritage en java, on aurait un pseudo classe qui serait "tout sauf..."
    3) au final on serati avec 2 groupes, les runtime et les pas runtime, ce qui ne résoud en rien le problème d'origine: traiter plusieurs exceptions (choisies) en un seul bloc.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et
    Laisse entrer le jour après une nuit sombre. Si tu es toujours là, tu n'es pas faite pour mourir.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •