IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

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%
Langage Java Discussion :

JDK 7: Proposition 7 : Pouvoir catcher plusieurs exceptions en une fois [Débat]


Sujet :

Langage Java

  1. #81
    Membre à l'essai
    Profil pro
    Architecte de système d’information
    Inscrit en
    Février 2008
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d’information

    Informations forums :
    Inscription : Février 2008
    Messages : 13
    Points : 16
    Points
    16
    Par défaut
    Pour la Proposition et pas hyper pour le '|'.

    Pour revenir sur le point de vue de jollyy
    Je suis plutôt pour, mais je crois je la vrai solution au merdier serait de changer la hierarchie des class d'Exception.

    Throwable devrait être unchecked.
    ...
    Exception devrait devenir unchecked (comme l'est RuntimeException).
    RuntimeException devrait être supprimée et une nouvelle class CheckedException devrait être créée et utilisée avec modération.
    Je partage le diagnostique et pense qu'il serait idéalement sain de remettre de l'ordre dans la hierarchie des exceptions.

    Par contre, je suis trés pas d'accord avec le remède proposé. Mettre Exception en unchecked, c'est autorisé tout les developeur a ne plus déclarer leur exception et donc a ne pas avoir obligation de prendre en compte les cas en erreur.

    Je m'inscris ici, bien sur, dans une vision au pire... mais mon expérience est qu'il est sain que la qualité du code ne dépendent pas que de l'éthique programmatique du développeur... éthique qui sera de toute façon mis à mal lors que le chef de projet / patron / client du dit développeur viendra lui mettre la préssion pour tenir la date de livraisoin.

  2. #82
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 144
    Points
    144
    Par défaut

    ça c'est super glop

    Après pour la syntaxe ... ouais pkoi pas changer. Moi j'aimais bien. Il y a quand même peu de chance de confondre une opération bit à bit avec ça, vu où c'est placé.

    Si ça avait été au milieu du code, j'aurais sursauté. Mais là franchement.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    try
    {
     ... 
    }
    catch(cet endroit)
    {
     ...
    }
    il y a peu de chance de trouver autre chose que le nom d'une exception placé à cet endroit

    Pour le foreach on a bien réutilisé le ":" déjà défini dans l'opérateur "? :". Il n'y a pas eu une si grosse vague de suicide parmi les développeurs qui n'ont pas supporté de voir le ":" de l'opérateur "? :" réutilisé dans le foreach. Je dirai même que ça a été plutot bien accueilli
    en plus le '|' voulant dire ou, je ne vois pas le problème.

  3. #83
    Expert éminent sénior


    Profil pro
    Inscrit en
    Mai 2003
    Messages
    3 240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 3 240
    Points : 11 101
    Points
    11 101
    Par défaut
    Je signale aussi que le | est déjà utilisé dans JDK 5 pour les Generics, et personne n'a crié au scandale jusqu'à présent. Et puis, le |, il veut bien dire ce que ca veut dire : OU.

    Vincent
    Vincent Brabant

    Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.

    Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java

  4. #84
    Membre averti

    Profil pro
    Coach Agile
    Inscrit en
    Décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Points : 371
    Points
    371
    Par défaut [OT] Calendrier
    Ma question n'est pas vraiment propre à cette proposition, mais a-t-on une idée du calendrier de traitement de l'ensemble de ces propositions ?

    Bref, il y a-t-il une deadline connue sur le retour de ces propositions à la commission qui tranchera sur leur bien fondé ?

    Chris

  5. #85
    Membre expérimenté
    Avatar de fabszn
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2002
    Messages
    974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2002
    Messages : 974
    Points : 1 638
    Points
    1 638
    Par défaut
    Hello,

    Je ne vais pas être original!

    Je suis pour, mais ...

    Pour en gardant l'ancienne syntaxe.
    En changeant le séparateur pour une virgule
    @+

    Fabszn
    Twitter : @fsznajderman

    N'oubliez pas le bouton
    Comment bien poser ses questions sur le forum


  6. #86
    Membre chevronné
    Avatar de CheryBen
    Inscrit en
    Mai 2005
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Âge : 42

    Informations forums :
    Inscription : Mai 2005
    Messages : 1 599
    Points : 2 197
    Points
    2 197
    Par défaut
    InstantiationException | IllegalAccessException e

    Pour, la syntaxe ne paraît pas si abhérente, on se retrouve avec un object e, et le | qui veut bien dire "ou" indique que e est une instance de InstantiationException ou IllegalAccessException.
    Ca permet de faire facilement des traitements génériques, par contre on risque de se retrouver avec des instanceof quelques fois. (si j'ai bien compris le principe)

  7. #87
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 11
    Points : 19
    Points
    19
    Par défaut
    Non à cause des développeurs de base qui vont utilsier la syntaxe pour tout catcher et faire des "if(e instanceof ...)"...

    Les audits de code que j'ai fait dans mon entreprise et qui ont été fait par des collègues me disent que trop de développeurs vont faire n'importe quoi.

    Et puis pour ce qu'on y gagne...

    Sun devrait plutôt se poser la question de la rétro-compatibilité et du prix réel à payer si on la cassait pour de vraies features.
    Ex : que les types[] et Object[] implémentent réellement Iterable et compagnie, pour que la boucle for(T o:iterable) ne soit plus un hack pour les tableaux.
    Autre Ex : que sur les Map "[]" soit équivalent à "get" ( => m.get("clé") serait équivalent à m["clé"]).
    Autre Ex : que les closures de Java 7 n'utilisent pas la syntaxe pourrie des closures dites "BGGA" (qui portent donc le nom de ses auteurs, sic), mais plutôt celle de javascript

  8. #88
    Candidat au Club
    Profil pro
    Inscrit en
    Février 2008
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    Citation Envoyé par Uther Voir le message
    Il me semble bien qu'il n'y a pas un seul endroit dans la syntaxe Java ou une classe est définie implicitement.
    Pourtant, toute classe hérite implicitement de java.lang.Object
    Quelle que soit la hiérarchie déclarée de ta classe, tu auras forcément ce que Object propose, et tu ne pourras pas faire sans cet héritage.

  9. #89
    Membre du Club
    Profil pro
    Inscrit en
    Août 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2005
    Messages : 73
    Points : 56
    Points
    56
    Par défaut
    Citation Envoyé par Uther Voir le message
    En fait ce n'est pas l'idée du tout. On ne peut pas et ne pourra pas catcher pas plusieurs exceptions en meme temps. Ce serait totalement incompatible avec la notion actuelle d'exception qui interromp le block d'execution.
    Il n'y a donc pas de question a ce poser de concaténation ou autre traitement particulier.

    La variable ne ne peux en effet etre du type ExceptionA ou ExceptionB, il faudra obligatoirement un ancêtre commun, ça pourrait être Throwable mais c'est réducteur. Je pense que le plus judicieux serait de spécifier cet ancêtre(cf ma proposition).
    Pour ça y a un truc très pratique :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    try{
    }catch(Exception e){
    }
    Pas besoin de nouvelle synthaxe pour ça ...

  10. #90
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Mon Dieu mais quelle horreur !

    Contre à 2^1024 %, pour la raison invoquée ici :

    Citation Envoyé par mavina Voir le message
    Personnellement je suis plutot contre. Le fait est qu'on puisse catcher des exceptions avec un ancetre commun comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    catch (PrinterAbortException, PrinterIOException : PrinterException e){
    }
    est la même chose que de catcher dirrectement l'ancetre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    catch (PrinterException e){
    }
    Et si l'on veut en catcher une autre du même ancetre dans un bloc différent, on la catch avant..
    Je pense pas que ce soit vital, le systeme actuel est relativement bien fait, ca n'apporte pas énormément.

    F.
    Que se passe-t-il quand on a des Exceptions de type très différents ? Tout ce que le compilateur peut faire, c'est rechercher un ancêtre commun à
    toutes les exceptions (au pire: Exception, qui est la classe de base de toutes les exceptions) et dans ce cas là, la proposition n'a strictement aucun intérêt.

    Sinon, en C# on peut faire ça (*) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    try
    {
       ...
     
    }
    catch (Exception e)
    {
      ExceptionA a = e as ExceptionA;
      if (a != null)
      {
         //  cette portion de code est exécutée, ssi e peut être casté en ExceptionA
         ...
      }
     
      if (e is ExceptionA || e is ExceptionB)
      {
         // exécuté si e peut être casté en ExceptionA ou ExceptionB
      }
     
    }
    C'est un peu dans l'esprit de départ, non ? (appliquer un même traitement à toute une famille d'exceptions, mais pouvoir appliquer des traitements spécifiques sur certains types d'exceptions) Et ça reste relativement lisible.

    Il me semble qu'il est possible de faire sensiblement la même chose en Java (mais je ne sais plus comment).


    (*) non, ce n'est pas un troll mais un élément de comparaison. On n'est pas dans la taverne.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  11. #91
    Membre averti

    Profil pro
    Coach Agile
    Inscrit en
    Décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Points : 371
    Points
    371
    Par défaut
    Citation Envoyé par zegreg Voir le message
    Pour ça y a un truc très pratique :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    try{
    }catch(Exception e){
    }
    Pas besoin de nouvelle synthaxe pour ça ...
    Je ne suis pas vraiment d'accord.
    Le notation proposée permet, entre autre, de regrouper des traitements d'exceptions de la sorte :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    try{
    } catch (ClassicException | DummyException e) {
    // traitement quelconque et commun à plusieurs exceptions
    } catch (SpecificException e) {
    // traitement spécifique
    } catch (Exception e) {
    // traitement générique des exceptions non prévues
    }
    Bref, cette notation nous laisse la possibilité de ne regrouper QUE les traitements d'exceptions que l'on souhaite, et qui auraient de toute façon fait l'objet d'un même traitement.

  12. #92
    Invité1
    Invité(e)
    Par défaut
    Pour. D'accord avec Uther concernant la syntaxe.

  13. #93
    Membre à l'essai
    Inscrit en
    Septembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Septembre 2007
    Messages : 22
    Points : 16
    Points
    16
    Par défaut
    Pour et personnellement la syntaxe ne me dérange pas plus que ça.

    Quoi que la syntaxe proposé par Uther n'est pas mal du tout.

  14. #94
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    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 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Que se passe-t-il quand on a des Exceptions de type très différents ? Tout ce que le compilateur peut faire, c'est rechercher un ancêtre commun à
    toutes les exceptions (au pire: Exception, qui est la classe de base de toutes les exceptions) et dans ce cas là, la proposition n'a strictement aucun intérêt.
    Si elle en a un !

    Lorsque tu fais ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    		try {
     
    		} catch (Exception e) {
    			log(e);
    		}
    Tu attrapes toutes les exceptions possibles, y compris les unchecked (NullPointer, ArrayIndexOutOfBound, IllegalArgument, etc..) qu'il est généralement préférable de faire remonter plutôt que d'intercepter...


    Alors que si tu fais :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    		try {
     
    		} catch (IOException | SQLException e) {
    			log(e);
    		}
    Tu n'attrapes QUE les IOException et SQLException et tu laisses remonter normalement les autres exceptions.



    De même, comment faire (proprement) avec un catch(Exception) si tu dois faire plusieurs traitements regroupés :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    		try {
     
    		} catch (Exception1 | Exception2 e) {
    			// Traitement A
    		} catch (Exception3 | Exception4 e) {
    			// Traitement B
    		}

    Citation Envoyé par pcaboche Voir le message
    Il me semble qu'il est possible de faire sensiblement la même chose en Java (mais je ne sais plus comment).
    Avec des instanceof... mais je trouve cela vraiment très crade :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    		try {
    			// ...
    		} catch (Exception e) {
    			if (e instanceof IOException) {
    				IOException ioe = (IOException) e;
    				// ...
    			} else {
    				// ...
    			}
    		}
    a++

  15. #95
    Membre expérimenté
    Avatar de fabszn
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2002
    Messages
    974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2002
    Messages : 974
    Points : 1 638
    Points
    1 638
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Avec des instanceof... mais je trouve cela vraiment très crade :
          Code  :
                  try {
                // ...
            } catch (Exception e) {
                if (e instanceof IOException) {
                    IOException ioe = (IOException) e;
                    // ...
                } else {
                    // ...
                }
            }
    Entièrement d'accord .. c'est pas propre du tout!
    @+

    Fabszn
    Twitter : @fsznajderman

    N'oubliez pas le bouton
    Comment bien poser ses questions sur le forum


  16. #96
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Et encore du sucre syntaxique... Decidement, Java 7 va finir par rendre tout le monde diabétique.

    Que Eclipse/Netbeans génère automatiquement 3 lignes catch(ExceptionX e), ou une seule ligne catch(Exception1|Exception2|Exception3 e)... bof...

    Je n'ai rien contre cette "amélioration", mais je ne crois pas que cela changera grand chose en pratique. Sur la quasi totalité des programmes que j'ai vu, il y a deux types de "catch":

    - les exceptions qu'on sait traiter, et donc qui ont du code "métier" dans le bloc catch{...}

    - les exceptions qu'on ne sait pas traiter, et donc qui sont au mieux "throwées", et plus généralement ignorées ("loguées" + "return null").
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  17. #97
    Membre du Club
    Profil pro
    Inscrit en
    Août 2005
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2005
    Messages : 73
    Points : 56
    Points
    56
    Par défaut
    Citation Envoyé par jproto Voir le message
    Je ne suis pas vraiment d'accord.
    Le notation proposée permet, entre autre, de regrouper des traitements d'exceptions de la sorte :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    try{
    } catch (ClassicException | DummyException e) {
    // traitement quelconque et commun à plusieurs exceptions
    } catch (SpecificException e) {
    // traitement spécifique
    } catch (Exception e) {
    // traitement générique des exceptions non prévues
    }
    Bref, cette notation nous laisse la possibilité de ne regrouper QUE les traitements d'exceptions que l'on souhaite, et qui auraient de toute façon fait l'objet d'un même traitement.
    La proposition d'Uther était de mettre des exceptions qui doivent avoir un ancêtre commun. Si on met cette restriction, je ne vois plus l'intérêt de créer une synthaxe spréciale...

  18. #98
    Membre averti

    Profil pro
    Coach Agile
    Inscrit en
    Décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Points : 371
    Points
    371
    Par défaut
    Citation Envoyé par zegreg Voir le message
    La proposition d'Uther était de mettre des exceptions qui doivent avoir un ancêtre commun. Si on met cette restriction, je ne vois plus l'intérêt de créer une synthaxe spréciale...
    J'y vois tout de même l'intérêt de pouvoir regrouper le traitement de plusieurs exceptions qui n'auront pas de hiérarchie commune, mais qui ferons l'objet d'un même traitement.

  19. #99
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Alors que si tu fais :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
            try {
     
            } catch (IOException | SQLException e) {
                log(e);
            }
    Tu n'attrapes QUE les IOException et SQLException et tu laisses remonter normalement les autres exceptions.
    Oui, et dans ce cas, e est de quel type ? IOException ou SQLException ? Si je fais Ctrl+Espace, comment l'IDE fait pour savoir de quel type est e et quels choix propose-t-il pour l'auto-complétion ?


    Citation Envoyé par adiGuba Voir le message
    Avec des instanceof... mais je trouve cela vraiment très crade :
    Oui, moi aussi je trouve ça très crade. Tellement crade que j'ai presque eu honte au moment d'écrire ces lignes. Mais c'était pour une bonne cause: montrer combien l'autre solution est encore plus crade (ça s'appelle "tendre la perche").

    En effet, rendez-vous compte: on déclare une variable qui, dans le code, peut-être tantôt d'un type, tantôt d'un autre. C'est du délire ! Au moins dans la version "crade", quand on déclare une variable, on connaît son type...


    Et puis dans la version "crade", on peut dessiner un squelette général pour le traitement des Exceptions (une sorte de template), avec quelques variantes pour certains types d'exceptions.

    A mon avis, l'une des grosses erreurs qui est faite en POO, c'est de vouloir systématiquement redéfinir les traitements par surcharge au niveau des sous-classes (="sur-spécialisation") au lieu de chercher les points communs entre les sous-classes et de définir le maximum de traîtements au niveau de la super-classe (="généralisation"). L'effet pervers de la spécialisation, c'est qu'à chaque nouvelle sous-classe on doit redéfinir certains traitements. C'est sûr, ça occupe les journées...



    Citation Envoyé par pseudocode Voir le message
    Et encore du sucre syntaxique... Decidement, Java 7 va finir par rendre tout le monde diabétique.
    +1000
    De plus, très bon jeu de mots !

    Cependant j'aurais plutôt opté pour le terme "arsenic syntaxique" (c'est un poison de donner ça à manger aux programmeurs).

    Citation Envoyé par zegreg Voir le message
    La proposition d'Uther était de mettre des exceptions qui doivent avoir un ancêtre commun. Si on met cette restriction, je ne vois plus l'intérêt de créer une synthaxe spréciale...
    +1000

    Citation Envoyé par jproto Voir le message
    J'y vois tout de même l'intérêt de pouvoir regrouper le traitement de plusieurs exceptions qui n'auront pas de hiérarchie commune, mais qui ferons l'objet d'un même traitement.
    Pas de hiérarchie commune ? Moi qui croyais que toutes les exceptions étaient des sous-classes de Exception et que quasiment tout en Java était une sous-classe d'Object (sauf les types de base: int, char...). On m'aurait menti ?
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  20. #100
    Membre régulier

    Homme Profil pro
    Développeur Java
    Inscrit en
    Mars 2002
    Messages
    65
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mars 2002
    Messages : 65
    Points : 99
    Points
    99
    Par défaut
    Bonjour,

    Le fait est que : un bloc de fonction peux générer plusieurs exceptions (cas général) qui auront en fin de compte le même traitement (propagation d'une exception générale à l'application, traitement de l'erreur de manniere sécurisé, etc...).

    Le fait de pouvoir intercepter plusieurs exception en une seule clause except me semble un idée louable si celle-ci nous laisse la possibilité de faire cela :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    try{
    } catch (ClassicException | DummyException e) {
    // traitement quelconque et commun à plusieurs exceptions
    } catch (SpecificException e) {
    // traitement spécifique
    } catch (Exception e) {
    // traitement générique des exceptions non prévues
    }
    Comme le propose jproto
    Cdlt

Discussions similaires

  1. [Débutant] Gestion de plusieurs exceptions dans une sub
    Par Attila54 dans le forum VB.NET
    Réponses: 14
    Dernier message: 17/08/2013, 20h29
  2. [FPDF] Générer plusieurs PDF en une fois
    Par mdr_cedrick dans le forum Bibliothèques et frameworks
    Réponses: 6
    Dernier message: 02/04/2009, 17h22
  3. [MySQL] plusieurs requetes en une fois
    Par maximenet dans le forum PHP & Base de données
    Réponses: 9
    Dernier message: 31/07/2006, 12h57
  4. [MFC] Checker plusieurs bouton en une fois
    Par kacedda dans le forum MFC
    Réponses: 2
    Dernier message: 08/03/2006, 18h10
  5. Réponses: 13
    Dernier message: 21/12/2005, 13h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo