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 6 sur 9 PremièrePremière ... 23456789 DernièreDernière
Affichage des résultats 101 à 120 sur 171
  1. #101
    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 pcaboche Voir le message
    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 ?

    Ce que je voulais dire par "Pas de hiérarchie commune" c'est aucune hiérarchie spécialisée. Il est évident que tout objet hérite de Object, et que toute exception hérite de Exception, mais sincèrement, il y a nombre de cas dans lesquels ce n'est pas exploité.
    Nombre de traitements d'exceptions se contentent d'appliquer un traitement "fonctionnel" à un nombre donné d'exceptions sans récupérer quoi que ce soit de l'objet Exception réellement émis. (sans compter les exception simplement ignorées ou relayées, mais ce n'est pas le sujet ici)

  2. #102
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 153
    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 153
    Points : 19 047
    Points
    19 047

    Par défaut

    Citation Envoyé par pcaboche Voir le message
    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 ?
    Perso je vois "e" comme une Exception ou plus généralement un Throwable, mais la proposition d'Uther en premier page est très intéressante puisqu'elle permet de spécifier un type parent...

    Dans les deux cas tu aurais accès à toutes les méthodes standard des exceptions ce qui est amplement suffisant dans la plupart des cas...

    Maintenant si tu as besoin d'utiliser des méthodes spécifiques à l'un ou l'autre des exceptions cela signifie que tu n'as pas un traitement commun et donc il faut utiliser deux catch !



    Citation Envoyé par pcaboche Voir le message
    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...
    Je ne comprend pas trop cette remarque : je ne vois pas pourquoi le type de l'exception changerait

    a++

  3. #103
    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 pcaboche Voir le message
    Mon Dieu mais quelle horreur !

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



    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.

    Tu veux surement parler de instanceof :

    Code :
    if(e instanceof Exception1 || e instanceof Exception2)
    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]

  4. #104
    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 adiGuba Voir le message
    Je ne comprend pas trop cette remarque : je ne vois pas pourquoi le type de l'exception changerait

    a++
    Admétons :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    try
    {
     //...
    }catch(IOException | SQLException e)
    {
        System.out.println(e.getSQLState());
    }
    Si on rentre dans le catch suite à un IOException, que fait java ?

    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]

  5. #105
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2004
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : février 2004
    Messages : 1 257
    Points : 1 775
    Points
    1 775

    Par défaut

    Citation Envoyé par mavina Voir le message
    Admétons :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    try
    {
     //...
    }catch(IOException | SQLException e)
    {
        System.out.println(e.getSQLState());
    }
    Si on rentre dans le catch suite à un IOException, que fait java ?

    F.
    Je pense que ça ne compile pas tout simplement.. "e" sera probablement de type exception.

    Avoir un catch commun est intéressant pour faire des actions communes. Mais c'est vrai que dans ce cas ce n'est pas très efficace autant avoir 2 catchs et éventuellement une méthode pour les actions communes. Surtout que la résolution de la signature d'une méthode se faisant a la compile, il est inutile de tenter une ruse avec la surcharge..

    Bulbo
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  6. #106
    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 mavina Voir le message
    Admétons :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    try
    {
     //...
    }catch(IOException | SQLException e)
    {
        System.out.println(e.getSQLState());
    }
    Si on rentre dans le catch suite à un IOException, que fait java ?

    F.
    Je voyais la réponse ici :

    Citation Envoyé par adiGuba Voir le message
    Maintenant si tu as besoin d'utiliser des méthodes spécifiques à l'un ou l'autre des exceptions cela signifie que tu n'as pas un traitement commun et donc il faut utiliser deux catch !
    Si tu fais appel à quoi que ce soit de spécifique à un objet d'exception en particulier, il est anormal d'utiliser ce type de syntaxe.
    A mon avis, cela mérite une nouvelle exception.

  7. #107
    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 bulbo Voir le message
    Je pense que ça ne compile pas tout simplement.. "e" sera probablement de type exception.

    Avoir un catch commun est intéressant pour faire des actions communes. Mais c'est vrai que dans ce cas ce n'est pas très efficace autant avoir 2 catchs et éventuellement une méthode pour les actions communes. Surtout que la résolution de la signature d'une méthode se faisant a la compile, il est inutile de tenter une ruse avec la surcharge..

    Bulbo
    Mais généralement on est dans ce cas, on n'a que très rarement deux exceptions de types quasiment égaux, et dans ce cas autant catcher l'exception mère la plus proche des exceptions de types quasiment égaux...

    Je ne vois pas où l'intêret de cette syntaxe peut se révèler parceque soit on catch deux exceptions proches dans le même bloc ce qui revient à catcher l'exception mere, soit on catch deux exceptions très "lointaines" dans deux blocs, ce que l'on fait déjà dans notre code actuellement...


    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]

  8. #108
    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 jproto Voir le message
    Si tu fais appel à quoi que ce soit de spécifique à un objet d'exception en particulier, il est anormal d'utiliser ce type de syntaxe.
    A mon avis, cela mérite une nouvelle exception.

    On est d'accordsur ce point. Alors si malgré toute la logique que tu as mise dans ta phrase, je décide quand même d'écrire ceci, que se passe-t-il ?

    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]

  9. #109
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 240
    Points
    1 240

    Par défaut

    Dans ce cas d'utilisation, je ne vois qu'une possibilité, moi : considérer e comme une Exception.
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    try {
      ...
    } catch (IOException | SQLException e) {
      e.getSQLState(); // ne compile pas car e est déclaré du type Exception et non de ses enfants.
      log.info(e);
    } catch (Exception e) {
      log.error(e);
    }
    Ce code permet simplement d'éviter d'écrire un instanceof ou de regrouper deux catch dont la fonctionnalité est identique et n'utilise que les méthodes d'Exception.

    Le multiple-catch doit être la contraction de ceci et uniquement ceci :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    try {
      ...
    } catch (IOException e) {
      log.info(e);
    } catch (SQLException e) {
      log.info(e);
    } catch (Exception e) {
      log.error(e);
    }
    Si on veut des traitements différents en fonction du type d'exception, c'est simple : la solution existe. Ici si la proposition ne rejoint pas ce que j'ai écrit, je ne le comprends pas, ni elle, ni son intérêt.

  10. #110
    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

    Citation Envoyé par dingoth Voir le message
    Le multiple-catch doit être la contraction de ceci et uniquement ceci :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    try {
      ...
    } catch (IOException e) {
      log.info(e);
    } catch (SQLException e) {
      log.info(e);
    } catch (Exception e) {
      log.error(e);
    }
    Si on veut des traitements différents en fonction du type d'exception, c'est simple : la solution existe. Ici si la proposition ne rejoint pas ce que j'ai écrit, je ne le comprends pas, ni elle, ni son intérêt.
    C'est exactement l'esprit de cette solution. Ne pas devoir, dans chaque catch, répeter le même code.

    Vincent
    Vincent Brabant

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

  11. #111
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 240
    Points
    1 240

    Par défaut

    Eh bien oui, la variable récupérée doit donc être de type Exception (ou au moins le plus grand ancêtre commun).

    Je ne comprends pas alors la réaction de Mavina : l'exception attrapée ne peut pas avoir de méthode getSQLState() sans être castée.

  12. #112
    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 dingoth Voir le message
    Eh bien oui, la variable récupérée doit donc être de type Exception (ou au moins le plus grand ancêtre commun).

    Je ne comprends pas alors la réaction de Mavina : l'exception attrapée ne peut pas avoir de méthode getSQLState() sans être castée.
    Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un
    Alors quel intérêt ?

    De plus tu parles de cast, il faudrait savoir : tu peux pas caster l'exception SQLException | IOException sans faire un instanceof pour être sur que c'est bien l'une ou l'autre...

    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]

  13. #113
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2004
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : février 2004
    Messages : 1 257
    Points : 1 775
    Points
    1 775

    Par défaut

    Citation Envoyé par mavina Voir le message
    Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un
    Alors quel intérêt ?
    Un petit exemple de l'intérêt de la chose:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    try
    {
    ....
    }
    catch (IOException | SQLException e)
    {
      // Traitement d'une exception lors de l'accès a une DB par exemple
    }
    catch(Exception e)
    {
      // Traitement d'un cas d'exception inattendu et peut-être fatale a l'application
    }
    J'ai eu ce cas dans un de mes codes ou j'ai du traiter 4 exceptions d'une certaine manière, une cinquième d'une autre et finalement un catch Exception pour le reste avec un sixième traitement.

    Bulbo
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  14. #114
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 153
    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 153
    Points : 19 047
    Points
    19 047

    Par défaut

    Citation Envoyé par mavina Voir le message
    Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un
    Alors quel intérêt ?
    Non ce n'est pas la même chose : avec un catch(Exception) tu attrapes toutes les exceptions possibles et imaginables, y compris les RuntimeExceptions qui ne devraient généralement pas être traités...

    De plus cela peut "cacher" d'autres exceptions : le compilateur ne t'avertira pas en cas où il y a d'autre exception "non traité" (que tu pourrais vouloir traiter différemment) puisque tu les traites toutes...

    On passe d'une gestion fine (en cas d'IOException ou de SQLException, je fais ceci) à un traitement global pour toutes les exceptions...


    Concretement :
    Code :
    1
    2
    3
    catch (IOException | SQLException e) {
        // traitement
    }
    Est plutôt strictement équivalent à :
    Code :
    1
    2
    3
    4
    5
    catch (IOException e) {
        // traitement
    } catch (SQLException e) {
        // traitement
    }
    (sans le double traitement bien sûr)



    Cela peut particulièrement être utile avec des APIs utilisant de multiples exceptions (comme c'est le cas pour la reflection), puisque cela te permet de regrouper les exceptions dans des groupes plus généraux (les erreurs de config, les erreurs de dev, les erreurs "rattrapables", ...).



    a++

  15. #115
    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
    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.
    oui, certes! Mais lit peut-être ce que je remet en cause !!!... L'intétêt d'avoir une syntaxe spéciale est justement de pouvoir catcher des exceptions qui ne sont pas communes. Faire un traitement pour des exceptions avec des ancêtres communs c'est déjà possible, pas besoin d'un débat pour cela...

  16. #116
    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 adiGuba Voir le message
    Non ce n'est pas la même chose : avec un catch(Exception) tu attrapes toutes les exceptions possibles et imaginables, y compris les RuntimeExceptions qui ne devraient généralement pas être traités...

    De plus cela peut "cacher" d'autres exceptions : le compilateur ne t'avertira pas en cas où il y a d'autre exception "non traité" (que tu pourrais vouloir traiter différemment) puisque tu les traites toutes...

    On passe d'une gestion fine (en cas d'IOException ou de SQLException, je fais ceci) à un traitement global pour toutes les exceptions...


    Concretement :
    Code :
    1
    2
    3
    catch (IOException | SQLException e) {
        // traitement
    }
    Est plutôt strictement équivalent à :
    Code :
    1
    2
    3
    4
    5
    catch (IOException e) {
        // traitement
    } catch (SQLException e) {
        // traitement
    }
    (sans le double traitement bien sûr)



    Cela peut particulièrement être utile avec des APIs utilisant de multiples exceptions (comme c'est le cas pour la reflection), puisque cela te permet de regrouper les exceptions dans des groupes plus généraux (les erreurs de config, les erreurs de dev, les erreurs "rattrapables", ...).



    a++
    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 ?

    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]

  17. #117
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 240
    Points
    1 240

    Par défaut

    Selon ma vision de la chose, je réponds oui à tes trois questions.

  18. #118
    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

    Pourquoi pas une syntaxe qui se rapprocherait du switch case adapté pour le catch ... car perso pas vraiment convaincu par les syntaxes proposées.
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    try{
     
    } 
    catch(ExceptionA e) :
    catch(ExceptionB e):
        traitement
        break;
    catch(ExceptionC e):
    ...
    Bon mon exemple n'est absolument pas au point, mais l'esprit y est , et ça permettrait d'éviter une syntaxe avec l'opérateur | qui a un sens déjà bien précis


    Ça ne résous pas les problèmes cités ci-dessus (utilisation de méthodes spécifiques), mais ça je crois pas que ce sera possible dans quelconque syntaxe proposée...

  19. #119
    Expert Confirmé Sénior


    Inscrit en
    octobre 2003
    Messages
    7 880
    Détails du profil
    Informations forums :
    Inscription : octobre 2003
    Messages : 7 880
    Points : 30 522
    Points
    30 522

    Par défaut

    Citation Envoyé par mavina Voir le message
    Mais généralement on est dans ce cas, on n'a que très rarement deux exceptions de types quasiment égaux, et dans ce cas autant catcher l'exception mère la plus proche des exceptions de types quasiment égaux...
    En faisant comme ca, tu imposes un traitement commun à toute une hiérarchie, y compris des classes d'exceptions que tu serais amené à créer par la suite. (on en revient alors au problème du catch (Exception) déjà évoqué).

  20. #120
    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 563
    Points
    7 563

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Perso je vois "e" comme une Exception ou plus généralement un Throwable, mais la proposition d'Uther en premier page est très intéressante puisqu'elle permet de spécifier un type parent...
    En intégrant la proposition d'Uther (avait pas vu...) et en spécifiant un peu :

    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
    try
    {
        ...
    }
    catch (T1 | T2 | T3 a : Ta)
    {
      // - Ta doit être compatible avec les types T1, T2 et T3
      // - a est de type Ta
      // - la portée de a se limite à ce bloc
      //
      // - Ta DOIT être spécifié pour faciliter la lecture du code
      //     ainsi que le travail du compilateur
     
      //  LÀ, AU MOINS, ON CONNAIT EXPLICITEMENT LE TYPE DE a !!!
     
    }
    catch (T4 | T5 b : Tb)
    {
      // - Tb doit être compatible avec les types T4 et T5
      // - b est de type Tb
      // - la portée de b se limite à ce bloc
      //
      // - Tb DOIT être spécifié pour faciliter la lecture du code
      //     ainsi que le travail du compilateur
     
      //  DE MÊME, ICI ON CONNAIT EXPLICITEMENT LE TYPE DE b !
     
    }
    catch (_)
    {
      // Les autres exceptions (ce bloc est facultatif)
    }
    C'est ça ?


    Dans ce cas, alors, pourquoi ne pas étendre le principe à d'autres types de variables que les exceptions ? Comme ceci :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    match (maVariable)
    with (T1 | T2 | T3 a : Ta)
    {
       // - Ta doit être compatible avec les types T1, T2 et T3
       // - a est de type Ta
       // - la portée de a se limite à ce bloc
    }
    with (T4 | T5 b : Tb)
    {
       // - Tb doit être compatible avec les types T4 et T5
       // - b est de type Tb
       // - la portée de b se limite à ce bloc
    }
    with (_)
    {
       // Les autres types d'objets
    }
    Je pense que vous aurez tous reconnu le langage qui a inspiré cette syntaxe (sauf que l'original est mieux, mais il faut bien essayer d'adapter aux spécificités de Java...).

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
  •