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 5 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 81 à 100 sur 171
  1. #81
    Candidat au titre de Membre du Club
    Inscrit en
    février 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 13
    Points : 14
    Points
    14

    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é
    Inscrit en
    mars 2005
    Messages
    148
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 148
    Points : 101
    Points
    101

    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 :
    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 Confirmé Sénior

    Inscrit en
    mai 2003
    Messages
    3 284
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 3 284
    Points : 9 776
    Points
    9 776

    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.

  4. #84
    Membre confirmé

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

    Informations forums :
    Inscription : décembre 2005
    Messages : 316
    Points : 281
    Points
    281

    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 Expert
    Avatar de fabszn
    Homme Profil pro Fabrice Sznajderman
    Développeur Java
    Inscrit en
    mars 2002
    Messages
    976
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Sznajderman
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2002
    Messages : 976
    Points : 1 529
    Points
    1 529

    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 Expert Avatar de CheryBen
    Inscrit en
    mai 2005
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Âge : 32

    Informations forums :
    Inscription : mai 2005
    Messages : 1 599
    Points : 1 935
    Points
    1 935

    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
    Candidat au titre de Membre du Club
    Inscrit en
    février 2007
    Messages
    11
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 11
    Points : 11
    Points
    11

    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
    Invité de passage
    Inscrit en
    février 2008
    Messages
    2
    Détails du profil
    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
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 35
    Points
    35

    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 :
    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 Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 477
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 477
    Points : 7 559
    Points
    7 559

    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 :
    1
    2
    3
     
    catch (PrinterAbortException, PrinterIOException : PrinterException e){
    }
    est la même chose que de catcher dirrectement l'ancetre :
    Code :
    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 :
    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.

  11. #91
    Membre confirmé

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

    Informations forums :
    Inscription : décembre 2005
    Messages : 316
    Points : 281
    Points
    281

    Par défaut

    Citation Envoyé par zegreg Voir le message
    Pour ça y a un truc très pratique :
    Code :
    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 :
    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
    Invité régulier
    Inscrit en
    septembre 2007
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 22
    Points : 6
    Points
    6

    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 Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 144
    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 144
    Points : 19 037
    Points
    19 037

    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 :
    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 :
    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 :
    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 :
    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 Expert
    Avatar de fabszn
    Homme Profil pro Fabrice Sznajderman
    Développeur Java
    Inscrit en
    mars 2002
    Messages
    976
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Sznajderman
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2002
    Messages : 976
    Points : 1 529
    Points
    1 529

    Par défaut

    Code :
    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/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 961
    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 961
    Points : 15 082
    Points
    15 082

    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
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 35
    Points
    35

    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 :
    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 confirmé

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

    Informations forums :
    Inscription : décembre 2005
    Messages : 316
    Points : 281
    Points
    281

    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 Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 477
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 477
    Points : 7 559
    Points
    7 559

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Alors que si tu fais :
    Code :
    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 ?

  20. #100
    Membre du Club
    Inscrit en
    mars 2002
    Messages
    65
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations forums :
    Inscription : mars 2002
    Messages : 65
    Points : 58
    Points
    58

    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 :
    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

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
  •