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 2 sur 9 PremièrePremière 123456 ... DernièreDernière
Affichage des résultats 21 à 40 sur 171
  1. #21
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2004
    Messages
    1 259
    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 259
    Points : 1 777
    Points
    1 777

    Par défaut

    Pour,

    mais comme beaucoup la syntaxe

    Mavina > Sans parler de l'ancêtre et de la propal du forum, ça peut éviter de dupliquer du code, ce qui est toujours un gain intéressant (coding + maintenance)

    J'ai le cas dans une grosse appli: j'ai un méthode qui lance un long processus et au cours de ce processus de nombreuses exceptions peuvent interrompre le tout.
    Certaines sont simplement redirigées vers l'utilisateur (via des dialogues), certaines provoquent un traitement automatique afin de silencieusement remettre tout en ordre et finalement le reste (de type Exception) qui va provoquer l'arrêt de l'appli avec rapport et stacktrace.
    J'aurais vraiment aimer n'avoir a écrire que trois block catch ce jour la..

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

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

    Par défaut

    Citation Envoyé par mavina Voir le message
    Bah le truc c'est que je vois pas quel intêret pourrait avoir cette notation, tu as un exemple concret qu'actuellement en java on ne peut pas faire et qui serait utile ?
    Cela permettrait de déterminer un comportement différent pour des exceptions différentes, par exemple pour les englober dans une exception commune, par exemple :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (IOException e) {
    			throw new MyException("erreur method", e);
    		} catch (SQLException e) {
    			throw new MyException("erreur method", e);
    		}
    	}
    On pourrait utiliser directement ceci (exemple avec la syntaxe de Uther que je trouve bien plus clair) :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (IOException, SQLException : Exception e){
    			throw new MyException("erreur method", e);
    		}
    	}

    Tu vas me dire on peut faire ceci :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (Exception e){
    			throw new MyException("erreur method", e);
    		}
    	}
    Oui mais ce n'est pas exactement la même chose : ici tu vas également récupérer toutes les RuntimeExceptions or ce n'est pas forcément voulu car elle représente plus une erreur dans le programme et qu'on aurait voulu les laisser remonter normalement...

    En fait actuellement il faudrait faire ceci afin d'ignorer les RuntimeException :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (RuntimeException e) {
    			throw e; // on remonte les RuntimeExceptions
    		}catch (Exception e){
    			throw new MyException("erreur method", e);
    		}
    	}


    De même cette solution n'est plus possible si tu as plusieurs types d'exception à gérer différemment :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    		try {
     
    			// ...
     
    		} catch (SQLException, IOException : Exception e){
    			// ... exceptions dû à une ressource inexistante ...
    		} catch (IllegalArgumentException, IllegalStateException : Exception e){
    			// ... exception dû à une mauvaise utilisation ...
    		}

    a++

  3. #23
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 042
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 042
    Points : 5 928
    Points
    5 928

    Par défaut

    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
    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.
    Pour l'exemple que tu donnes c'est en effet la même chose, vu que PrinterAbortException et PrinterIOException sont les 2 seules classes filles de PrinterException.

    Par contre dans ce cas:
    Code :
    catch(ClassCastException, NullPointerException : RuntimeException e){...}
    Cela permettrait de catcher les erreurs de classcast et nullpointer mais pas les autres RuntimesException comme les divisions par 0.

  4. #24
    Membre expérimenté
    Inscrit en
    juillet 2007
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 769
    Points : 542
    Points
    542

    Par défaut

    Je suis contre, absolument contre. Cette proposition vient pervertir le langage pour une avancée tout à fait mineure. De plus, il est déjà possible de catcher plusieurs type d'exceptions à la fois si elles héritent d'un supertype commun.

  5. #25
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2004
    Messages
    1 259
    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 259
    Points : 1 777
    Points
    1 777

    Par défaut

    Citation Envoyé par verbose Voir le message
    Je suis contre, absolument contre. Cette proposition vient pervertir le langage pour une avancée tout à fait mineure. De plus, il est déjà possible de catcher plusieurs type d'exceptions à la fois si elles héritent d'un supertype commun.
    Ca c'est dans le cas ou tu as la main sur tout les types d'exceptions qui peuvent être levées par ton programme.
    Au jour d'aujourd'hui vu le nombre d'API sur le marché qui peut dire qu'il maitrise la conception de toutes les classes qu'il utilise ?

    Dans l'absolu il y a une avancée, mineure mais il y en a une.

    La 'perversion' du langage est vraiment mineure, limitée et facilement lisible (mais ce | brr ) contrairement a bien d'autres proposées ailleurs.

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

  6. #26
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Tu vas me dire on peut faire ceci :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (Exception e){
    			throw new MyException("erreur method", e);
    		}
    	}
    Oui mais ce n'est pas exactement la même chose : ici tu vas également récupérer toutes les RuntimeExceptions or ce n'est pas forcément voulu car elle représente plus une erreur dans le programme et qu'on aurait voulu les laisser remonter normalement...

    En fait actuellement il faudrait faire ceci afin d'ignorer les RuntimeException :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    	public static void method() throws MyException {
    		try {
     
    			// Code pouvant renvoyer des IOException / SQLException
     
    		} catch (RuntimeException e) {
    			throw e; // on remonte les RuntimeExceptions
    		}catch (Exception e){
    			throw new MyException("erreur method", e);
    		}
    	}


    De même cette solution n'est plus possible si tu as plusieurs types d'exception à gérer différemment :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    		try {
     
    			// ...
     
    		} catch (SQLException, IOException : Exception e){
    			// ... exceptions dû à une ressource inexistante ...
    		} catch (IllegalArgumentException, IllegalStateException : Exception e){
    			// ... exception dû à une mauvaise utilisation ...
    		}
    Merci pour cet exemple qui tient bien la route Je pense que c'est plus parlant comme ça.

    Je compatis avec bulbo, car moi aussi dans une grosse appli, je gère plusieurs classes d'exceptions à un niveau différent, et ça demande des catch à rallonge, ce qui est pour moi une grande source de bugs

  7. #27
    Membre émérite Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 863
    Points
    863

    Par défaut

    Pour mais avec la syntaxe d'Uther.

  8. #28
    Rédacteur/Modérateur
    Avatar de le y@m's
    Homme Profil pro Yann D'Isanto
    Ingénieur développement logiciels
    Inscrit en
    février 2005
    Messages
    2 640
    Détails du profil
    Informations personnelles :
    Nom : Homme Yann D'Isanto
    Âge : 31
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : février 2005
    Messages : 2 640
    Points : 5 499
    Points
    5 499

    Par défaut

    Pour, mais comme déjà dit la syntaxe ne me paraît pas judicieuse.
    Je ne répondrai à aucune question technique par MP.

    Pensez aux Tutoriels et aux FAQs avant de poster (pour le java il y a aussi JavaSearch), n'oubliez pas non plus la fonction Rechercher.
    Enfin, quand une solution a été trouvée à votre problème
    pensez au tag

    Cours Dvp : http://ydisanto.developpez.com
    Blog : http://yann-disanto.blogspot.com/
    Page perso : http://yann-disanto.fr

  9. #29
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 984
    Points
    984

    Par défaut

    Citation Envoyé par Uther Voir le message
    Pour le principe mais à condition d'utiliser une autre syntaxe.

    Le "|" comme séparateur m'a fait sursauter. Ca me parrait une très mauvaise idée d'utiliser comme séparteur le même symbole qu'un opérateur binaire .
    De plus, la classe de l'exception commune "e" n'est pas spécifié ce qui n'est pas naturel dans un catch(et en java tout court même).

    Je verais plutôt une syntaxe du style:
    Code :
    1
    2
    3
    ...
    catch (InstantiationException, IllegalAccessException : Exception e){
    ...
    +1

  10. #30
    Expert Confirmé Sénior
    Avatar de elitost
    Homme Profil pro Eric REBOISSON
    Consultant informatique
    Inscrit en
    septembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Eric REBOISSON
    Âge : 37
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 986
    Points : 6 245
    Points
    6 245

    Par défaut

    Encore une fois pour les possibilités de raccourcir le code , mais ici une syntaxe à explorer...

  11. #31
    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

    Vu sous cet angle, oui mais pourquoi annoncer le parent dans le catch ?

    pourquoi annoncer
    Code :
    catch(MonExcFille1,MonExcFille2 : MonExcMere)
    et pas juste les exceptions filles? Je trouve que donner la classe mere ne sert pas à grand chose.

    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. #32
    Membre expérimenté
    Inscrit en
    juillet 2006
    Messages
    548
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 548
    Points : 548
    Points
    548

    Par défaut

    Citation Envoyé par mavina Voir le message
    Vu sous cet angle, oui mais pourquoi annoncer le parent dans le catch ?

    pourquoi annoncer
    Code :
    catch(MonExcFille1,MonExcFille2 : MonExcMere)
    et pas juste les exceptions filles? Je trouve que donner la classe mere ne sert pas à grand chose.

    F.
    Il faut déclarer une classe parente, sinon dans ce code:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    catch(MonExcFille1,MonExcFille2 : MonExcMere e) {
      processException(e);
    }
     
    public void processException(MonExcFille1 e) {
      // ...
    }
     
    public void processException(MonExcFille2 e) {
      // ...
    }
     
    public void processException(MonExcMere e) {
      // ...
    }
     
    public void processException(Exception e) {
      // ...
    }
    Le compilateur ne saura pas vers quel méthode résoudre processException().

  13. #33
    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 OButterlin Voir le message
    Oui, et même restriction pour la syntaxe (plutôt "," que "|")
    D'un autre côté, qu'est-il prévu pour la gestion de l'objet exception proprement dit ?
    On le traite comme Throwable, Exception ou le premier ancêtre commun ?
    Cette dernière pourrait être intéressante...
    Le compilateur / IDE prendrait automatiquement la classe commune dans la hiérarchie. Donc pas de cast nécessaire et recours aux méthodes "communes" dans le block catch. Ce qui peut donc expliquer l'absence de la définition de cette classe puisque le compilateur saura la déterminer.

    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.
    Et si tu ne veux justement pas catcher l'une des classes filles de PrinterException ?

    Citation Envoyé par the-gtm Voir le message
    Il faut déclarer une classe parente, sinon dans ce code:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    catch(MonExcFille1,MonExcFille2 : MonExcMere e) {
      processException(e);
    }
     
    public void processException(MonExcFille1 e) {
      // ...
    }
     
    public void processException(MonExcFille2 e) {
      // ...
    }
     
    public void processException(MonExcMere e) {
      // ...
    }
     
    public void processException(Exception e) {
      // ...
    }
    Le compilateur ne saura pas vers quel méthode résoudre processException().
    L'appel est résolu au Runtime en fonction de l'exception, donc je ne vois pas ce que le compilateur ferait dans l'histoire si ce n'est vérifier que tous les cas sont couverts.

  14. #34
    Membre expérimenté
    Inscrit en
    juillet 2006
    Messages
    548
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 548
    Points : 548
    Points
    548

    Par défaut

    Je sais pas si c'est résolu au runtime ou à la compilation, mais en tout cas ça la méthode sélectionnée dépend du type déclaré de la variable. cf 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
    public class ExceptionTest {
     
    	public static void main(String[] args) {
    		new ExceptionTest().test();
    	}
     
    	public void test() {
    		MonExcMere e1 = new MonExcFille1();
    		processException(e1);
    	}
     
    	public void processException(MonExcFille1 e) {
    		System.out.println("MonExcFille1");
    	}
     
    	public void processException(MonExcFille2 e) {
    		System.out.println("MonExcFille2");
    	}
     
    	public void processException(MonExcMere e) {
    		System.out.println("MonExcMere");
    	}
     
    	class MonExcFille1 extends MonExcMere {}
    	class MonExcFille2 extends MonExcMere {}
    	class MonExcMere {}
    }
    C'est "ExceptionMere" qui est affiché, parce que la variable a été déclarée comme une ExceptionMere

  15. #35
    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 Ricky81 Voir le message
    Et si tu ne veux justement pas catcher l'une des classes filles de PrinterException ?
    Tu la catch à part avant non ?

    Un truc du genre
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    try
    {
    (...)
    }catch(PrinterAbortException pae)
    {
    //je ne fais rien
    }catch(PrinterException pe)
    {
    //je fais
    }
    passe dans le premier catch lors d'une PrinterAbortException et dans le
    second lors du reste non ? J'avoue n'avoir jamais eu ce cas ...

    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]

  16. #36
    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

    Je me suis mal exprimé en parlant de Runtime. Le catch multiple n'est que du sucre syntaxique, c'est comme si on écrivait un bloc catch par exception déclarée, donc le problème que tu évoques ne devrait arriver.

    mavina là tu étouffes l'exception, il s'agirait de la propager tout simplement.

  17. #37
    Membre expérimenté
    Inscrit en
    juillet 2006
    Messages
    548
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 548
    Points : 548
    Points
    548

    Par défaut

    Citation Envoyé par Ricky81 Voir le message
    Je me suis mal exprimé en parlant de Runtime. Le catch multiple n'est que du sucre syntaxique, c'est comme si on écrivait un bloc catch par exception déclarée, donc le problème que tu évoques ne devrait arriver.
    Je pense que je vois ce que tu veux dire : en gros c'est équivalent à plusieurs blocs catchs, chacun avec une exception en particulier.

    Ca me semble quand même ambigu comme syntaxe. Si on reprend l'exemple

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    catch(MonExcFille1,MonExcFille2 e) {
      processException(e);
    }
     
    public void processException(MonExcFille1 e) {
    	System.out.println("MonExcFille1");
    }
     
    public void processException(MonExcFille2 e) {
    	System.out.println("MonExcFille2");
    }
    Si dans mon IDE je rentre dans la méthode du bloc catch(F3 avec eclipse), il m'ouvre laquelle?
    En gros ça revient à mettre un peu de langage dynamique dans Java. C'est le "un peu de" qui me gène, soit le typage est dynamique soit il est statique, quand "ça dépend", c'est pas terrible

  18. #38
    Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 460
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 37
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 460
    Points : 9 143
    Points
    9 143

    Par défaut

    Pour, mais avec une syntaxe differente (des virgules semblent tout indiquees pour le travail).
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  19. #39
    Membre chevronné

    Profil pro
    Inscrit en
    juillet 2002
    Messages
    346
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : juillet 2002
    Messages : 346
    Points : 666
    Points
    666

    Par défaut

    Pareil que beaucoup, pour la proposition mais contre la syntaxe (au minimum utiliser une virgule), la possibilité offerte de définir le type de l'exception passée au bloc catch permet aussi de ne pas devoir faire de 'instance of' pour déterminer le typage de l'exception dans le bloc catch si nécessaire.

    Donc, +1 pour la syntaxe de Uther.

  20. #40
    Rédacteur
    Avatar de benwit
    Inscrit en
    septembre 2004
    Messages
    1 670
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 1 670
    Points : 3 147
    Points
    3 147

    Par défaut

    Citation Envoyé par Uther Voir le message
    Pour le principe mais à condition d'utiliser une autre syntaxe.

    Le "|" comme séparateur m'a fait sursauter. Ca me parrait une très mauvaise idée d'utiliser comme séparteur le même symbole qu'un opérateur binaire .
    De plus, la classe de l'exception commune "e" n'est pas spécifié ce qui n'est pas naturel dans un catch(et en java tout court même).

    Je verais plutôt une syntaxe du style:
    Code :
    1
    2
    3
    ...
    catch (Exception e : InstantiationException, IllegalAccessException){
    ...
    +2

    Edité pour modif de syntaxe (cf ci dessous)

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
  •