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 9 sur 9 PremièrePremière ... 56789
Affichage des résultats 161 à 171 sur 171
  1. #161
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

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

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 680
    Points : 6 961
    Points
    6 961

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    La seule chose que Java impose, c'est de déclarer les checked-exception que l'on remonte...
    a++
    T'avais peut être raison sur la stacktrace, j'ai peut être confondu c# et java lorsque j'ai dit qu'un throw ex; modifiait la stacktrace de ex. En c# c'est ce qui se produit, pour java pas le coeur de vérifier alors je te crois sur parole.
    Mais le problème de fond reste toujours le même, si tu relances une exception de type "Exception" tu devras décorer toutes tes méthodes de throws Exception ce qui casse tout le concept.

  2. #162
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 270
    Points
    270

    Par défaut

    Citation Envoyé par _skip Voir le message
    -Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.
    Justement, je ne parles pas de ce qu'impose java, mais de ce que l'on s'impose à soi même pour garder un code propre donc maintenable.

    -finally ça se déclenche aussi si tout s'est bien passé, c'est l'endroit idéal pour libérer des ressources mais pas pour effectuer un rollback.
    Euh oui, là j'ai déconné à plein tube, finally c'est plutôt pour une fermeture de connection, de fichier...
    il n'empêche que le cas du rollback est justement particulier: on doit le faire au plus haut niveau du service pour annuler toutes les opérations du service, ce qui rejoint mon cas de service de haut niveau.
    Et du reste, on doit refaire un try catch dans le catch car on n'est pas sûr d'avoir toujours la connection si l'exception est justement une coupure de connection.

  3. #163
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 023
    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 023
    Points : 20 799
    Points
    20 799

    Par défaut

    Citation Envoyé par _skip Voir le message
    Mais le problème de fond reste toujours le même, si tu relances une exception de type "Exception" tu devras décorer toutes tes méthodes de throws Exception ce qui casse tout le concept.
    Dans le cas des checked-exceptions seulement (ce qui n'existe pas en C#).

    Si tu manipules des unchecked-exceptions (RuntimeException en Java) tu te retrouveras exactement dans le même cas qu'en C#.

    Maintenant on pourrait faire un débat sur l'intérêt des checked-exception, mais c'est un autre sujet.

    a++

  4. #164
    Membre éclairé
    Inscrit en
    décembre 2007
    Messages
    222
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 222
    Points : 311
    Points
    311

    Par défaut

    Pour, mais avec une syntaxe bien pensée.

  5. #165
    Membre du Club
    Inscrit en
    août 2008
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 47
    Points : 46
    Points
    46

    Par défaut

    C'est vrai que voir un separateur | comme ça, me fait plutot penser soit à du C pour separer des options du genre O_CREAT | O_RDWR soit à de l'OCaml pour separer des constructeurs ABR = Nil | Node of (int*ABR*ABR)
    Mais pas habitué à ça en java pour ma part.

    J'aimerais avoir une façon simple de catcher toutes les exceptions d'un coup sans avoir à faire une chaine à ralonge.

  6. #166
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 023
    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 023
    Points : 20 799
    Points
    20 799

    Par défaut

    Citation Envoyé par nonpoluant Voir le message
    C'est vrai que voir un separateur | comme ça, me fait plutot penser soit à du C pour separer des options du genre O_CREAT | O_RDWR soit à de l'OCaml pour separer des constructeurs ABR = Nil | Node of (int*ABR*ABR)
    Mais pas habitué à ça en java pour ma part.
    Cela existe pourtant aussi en Java et la signification est très claire : "OU" !

    Citation Envoyé par nonpoluant Voir le message
    J'aimerais avoir une façon simple de catcher toutes les exceptions d'un coup sans avoir à faire une chaine à ralonge.
    Pour catcher toutes les exceptions on peut utiliser catch(Exception)... mais ce n'est pas très propre et peut poser d'autres problèmes (comme traiter des exceptions que l'on ne souhaiterais pas).


    a++

  7. #167
    Invité de passage
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : octobre 2008
    Messages : 4
    Points : 4
    Points
    4

    Par défaut Pour

    Pour, à condition de pouvoir spécifier le type de l'erreur attrapée :

    Code :
    1
    2
    3
    4
    5
    6
    7
    try {
    	// Tentative
    }
    catch (SQLException e : SQLWarning | BatchUpdateException) {
    	// Echec
    	e.getSQLState();
    }
    C'est plus précis que :

    Code :
    1
    2
    3
    4
    5
    6
    7
    try {
    	// Tentative
    }
    catch (SQLException e) {
    	// Echec
    	e.getSQLState();
    }
    car on attrape pas toutes les SQLException.
    En même temps cela évite les lourdeurs du type :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    try {
    	// Tentative
    }
    catch (SQLWarning e) {
    	// Echec
    	e.getSQLState();
    }
    catch (BatchUpdateException e) {
    	// Echec
    	e.getSQLState();
    }
    En cas d'omission du type de retour il pourrait être interprété comme étant simplement Exception. En effet, la plupart des exceptions usuelles ne comportent pas de méthodes en plus de celles déclarées dans Exception.

  8. #168
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2008
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mars 2008
    Messages : 20
    Points : 22
    Points
    22

    Par défaut Mouuuai

    Citation Envoyé par Gargamail Voir le message
    Contre.
    À mon avis,
    • soit il y a une classe/interface mère pour les exceptions qu'on veut regrouper,
    • soit les exceptions sont mal définies et cette classe/interface mère devrait exister.
    Je suis de cet avis. Ce n'est pas peine de compliquer les choses. Si c'est vraiment le même traitement, il suffit de le mutualiser dans une méthode privée.

  9. #169
    Inactif
    Profil pro Alexandre Jaquet
    Inscrit en
    mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Nom : Alexandre Jaquet
    Âge : 33

    Informations forums :
    Inscription : mai 2006
    Messages : 2 189
    Points : 1 902
    Points
    1 902

    Par défaut

    pourquoi pas un

    catch(Exception ...exs) {

    }

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

    Informations forums :
    Inscription : avril 2002
    Messages : 2 960
    Points : 6 047
    Points
    6 047

    Par défaut

    Déjà posé plusieurs fois.
    J'ai la flemme de la refaire en complet mais avec un catch sur Exception, on va catcher toutes les exceptions y compris les exceptions unchecked(null pointeur, division par 0, ...) qui normalement ne sont pas interceptées.

  11. #171
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 270
    Points
    270

    Par défaut Solution adoptée par Sun

    Selon les articles suivants, cette partie sera intégrée à Java 7 avec des | comme séparateurs:

    http://tech.puredanger.com/2009/02/16/java7-update/
    http://tech.puredanger.com/java7
    https://jdk7.dev.java.net/
    http://blogs.sun.com/theplanetarium/...ge_changes_for

    ça pourrait faire l'objet d'un nouveau Thread unique pour tout java7, le débat sur les nouveautés java7 est obsolète?

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
  •